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[57] ABSTRACT 

A method and apparatus for operating a computer 
graphics system to perform a conditional test on a node 
in a graphics data structure during the traversal of the 
graphics data structure by a structure walker. The 
graphics system is operated to manipulate data con- 
tained in a memory to define a value for an operand that 
is to be tested. The system accesses the operand from 
the memory. A structure walker performs a test on the 
value of the operand during traversal of the graphics 
data structure. Depending upon the result of the test, 
the structure walker traverses one of several paths in 
the graphics data structure to create a graphics display. 

6 Claims, 14 Drawing Sheets 
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This application is a continuation, of application Ser. 
No. 184«406, filed Apr. 20, 19S8, now abandoned, which 
is a continuation of application Ser. No. 083,081 filed 
Aug. 13, 1987 now US. Pat No. 5,153.822. 

BACKGROUND OF THE INVENTION 

A. Field of the Invention 

The invention relates to a computer graphics work- 
station and, neiore particularly, to a high performance, 
stand-alone graphics workstation including a digital 13 
computer host and a graphics processing subsystem. 
The invention provides efficient control structures to 
obtain a maximum utilization of system resources and to 
effectively coordinate operation among essentially data- 
driven, asynchronous components and thereby enable 20 
both two-dimensional and three-dimensional high reso- 
lution graphics displays. 

B. Prior Graphics Systems 

In recent years considerable advances have been 
made in the utilization of computer systems to generate 23 
and visually display character and graphical output 
data. The earhest systems were limited to two-dimen- 
aonal displays very often realized through the use of 
alphanumeric characters. The graphics data generation 
capability of such early systems was limited and certain 30 
character representations of predetermined size and 
shape were stored in a character data memory and were 
transferrable to a display memory by the user, when 
desired, to expand the display capability of the system. 
A noteworthy advance in the computer graphics art 33 
involved the use of a so-called '1)it mapped** graphics 
display system to store output data in a display memory. 
The "bit mapped" approach visualizes the output data 
as a two-dimensional array of pixels, where each pixel 
corresponds to an individual picture element in the 40 
display device. In a two-dimensional, black and white 
graphics dbplay, each pixel need only contain one bit of 
information, i.e. either 0 or 1 to represent either black or 
white, respectively. Accordingly, all of the pixels for a 
two-dimensional, black and white display may be in the 45 
form of a two-dimensional map where the bits of infor- 
mation in the map comprise the output data represent- 
ing the display device. 

As should be understood, the graphic display of a 
three-dimensional object in color, as opposed to a two 50 
dimensional object in black and white substantially 
increases the amount of output dau required to repre- 
sent the display device and the processing capability of 
the graphics system required to process the output data 
for display on a cathode ray tube. For instance, with 33 
respect to color alone, eight bits of information per pixel 
may be required to store information on the red, green 
and blue components of the color and the intensity of 
the color for display. 

The bit mapped approach was expanded by the prior 60 
art to a planar concept wherein a three-dimensional 
array is visualized with separate spaced, parallel planes, 
each plane corresponding to one attribute of the color 
information, i.e., a red plane, a green plane, a blue plane 
and an intensity plane. Each pixel comprises bits stored 63 
on the separate planes and data processing requires the 
graphics system to retrieve the separate bits of a pixel 
from among several memory locations. 



322 

2 

When other attributes and display characteristics 
such as a three-dimensional display, shading, surface 
reflective qualities, object rotation, etc. are to be added 
to the graphics system, the memory structure and ca- 
pacity and data processing capability of the system must 
be greatly expanded to represent and visually display an 
object Such capacity, structure and processing capabil- 
ity requirements have generally limited the feasibility of 
implementing a high performance, three-dimensional 
graphics system as a stand-alone, worksution-type sys- 
tem particularly a graphics system with a multi-user 
capability. While technological advances such as a 32 
bit word microprocessor provide a hardware basis for a 
stand-alone, workstation implementation for a graphics 
system, there remain formidable data structure and 
processing and system operational control requirements 
to achieve an effective high performance graphics 
workstation system capable of processuig multiple ap- 
plication processes to permit a multi-user implementa- 
tion. These requirements have not been adequately 
addressed by the prior art 

SUMMARY OF THE INVENTION 

Accordingly, it is a primary objective of the inven- 
tion to provide a stand-alone, graphics workstation that 
accomplishes the data structure and processing and 
system operational control necessary for high perfor- 
mance, high resolution graphics display with a multi- 
user capability. 

Generally, the system of the invention comprises a 
host central processing unit connected by means of an 
intermediate processing unit and a bus arrangement to a 
graphics subsystem. The host subsystem is operable to 
execute one or more application programs residing in 
the host to build graphics data structures representing 
two dimensional and/or three-dimensional objects to be 
displayed. The graphics data structures are stored in a 
structure memory component in the graphics subsys- 
tem. The three-dimensional graphics data structures are 
each implemented as a hierarchical graphics data node 
structure in the structure memory. For a thorough dis- 
cussion of the principal concepts of interactive com- 
puter graphics as generally employed by the system of 
the invention, reference should be made to Fundamen- 
tels of Interactive Computer Graphics by J. D. Foley 
and A. Van Dam (Addison-Wesley 1982). 

Each node is defined as a fundamental memory unit 
to contain graphics data or commands relating to the 
primitives, transformations, attributes and so on of the 
graphics structure being built pursuant to a specific 
application program residing in the host through the 
utilization of preselected structured graphics routines 
stored in a memory library, also in the host An asyn- 
chronously operational structure walker in the graphics 
subsystem traverses a special control structure stored m 
the structure memory on a continuing basis to read and 
process requests for traversal of the nodes of the graph- 
ics structures and to send the data and conunand infor- 
mation contained in the nodes down a graphics pipeline 
for processing, manipulation and display by the graph- 
ics processing components of the grapl^cs subsystem. 

Hierarchical graphics data structure are built using 
reference nodes. A reference node instructs the struc- 
ture walker to traverse another substructure of the call- 
ing structure before continuing with the traversal of the 
structure containing the reference node. Reference 
nodes can be either conditional or unconditional. Con- 
ditional nodes select one among two or more alternate 
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traversal paths depending on the value of one or two FIO. 12 is a block diagram of the bitmap display 

operands. context. 

Other nodes used to create advanced graphics data FIG. 13 illustrates, in block diagram form, the con- 
structures include assignment nodes and special purpose nection between a graphics context and the virtual root 
nodes. Assignment nodes set up and manipulate the 5 node of a data structure. 

values that are tested by conditional reference nodes FIGS. I4a, \4b, 14c illustrate examples of various 

thus permitting dynamic control of how a given condi- reference nodes. 

tional reference nodes select the path traversal. Special _ 

pumose nodes allow the buildSig of custom ^es DETAILED DESCRimON OF A PREFERRED 

which use the same data at different places in the struc 10 EMBODIMENT OF THE INVENTION 

ture and store unused data. Special purpose nodes pro- System Overview 

vide increase flexibilily by allowing the application to , , j j • « * m 

tailor a dau structure for its own needs. Rcfer™g now to the draMongs and^^^^^^ 

The conditional reference nodes used to create ad- ^^^rc is illustrated, m block diagram form, the graphics 

vanced graphics data structures redirect the traversal 15 workstation system accordmg to the mvention. A host 

path of the structure walker based upon cither true/- subsystem includes a host central proccsang umt 10, a 

Sse test or a value comparison. The test performed by host memory 11, a tape controller 12, a control proccs- 

the conditional reference nodes uses values stored in sor 13 and a disk controller 14. The host subsystem 

one or two operands in the node. The value of the oper- components 10, 11, 12, 13 arc interfaced with one an- 

ands are set by the manipulations of the assignment 20 other by means of a bus 15. 

nodes. The operands are retrieved by using one of four A preferred host subsystem for advantageous imple- 

access modes. mentation of the teachings of the invention comprises a 

The access modes are specified by constants set in the Scorpio or Digital KA825 host processor utilized as the 

mode parameters of the routine that creates the node. host central processing unit 10, a 4-Mbyte MS820-BA 

The access modes tell the system how to interpret the 23 memory module as the host memory 11, a DEBNx 

operational speciHer parameter argument of the routine. Ethernet local area network and TKSO 95 Mbyte 

The test performed by the conditional reference node streaming tape drive as the tape controller 12, and 

uses the value of the operand at the time of traversal. RD54 150-Mbyte nonremovable-disk drive and an 

Operand access modes are important in the use of RX50 818-kbyte diskette drive as the disk controller 14, 
assignment and reference nodes. By using the access JO an Aurora or Digital 1CA800 control processor to func- 
modes, assignment nodes create additional data or gen- ^qj^ as the control processor 13 and a VAX Bus Inter- 
eral data in the structure memory. The reference nodes connect or VAX BI synchronous, time-multiplexed, 
can then branch according to their data created. The 32.^,11 bus as the bus 15. The Scorpio processor in a 
use of special purpose nodes allows the data to be sent ^^^^ board VAX processor which executes the corn- 
to the graphics subsystem. In this way. the data struc- 55 vAX instruction set and runs either the VMS or 
ture in effect writes a "subprogram** and executes it ULTRIX operating system and applications. The Scor- 
during the traversal of the structure. This proxies a |,ost processor, Aurora control processor, VAX Bl 
more general functionality as well as a more efTicient ^^^j ^^^er host subsystem components are marketed 
use of memory resources. , ^ ^ ^ u t>y Digital Equipment Corporation. 

For a better understanding of the above and other 40 ^^^^^^j ^^^^^ ,3 provided with a local or 

features and advantages of the mvention, reference interface the comrol processor 13 with a 

should be made to the following detailed description of graphics subsystem 17. The Aurora control processor 

a preferred embodiment of the invention and to the ^3 therefore acts as an interface between the graphics 

accompanying drawings. subsystem 17 and the BI bus IS. The control processor 

BRIEF DESCRIPTION OF THE DRAWINGS 13 also performs input and output pre-processing for 

I J- r interactive perphireal devices such as a keyboard 18, a 

FIG. 1 .s . block diagnm. of a coinpuier graph.es ^^^^^ ^ ^ ^^^^^ ^ 

system in accordance w.th '''^Pr"™; which are connected to the control processor 13 by 

FIG. 2 IS a block diagram of the graph.cs subsystem ^ ^ ^^^^^^^ ^^^^ 23 thmugh a serial 

Fiaais a block diagram of the software organiza- "ata line 24. as illustrated in FIG. 1. The .peripheral 

iTjy. ^ « o w»vw t *um Zr^^t repeater box 23 is utilized to power the penpheral de- 

tion for the computer graphics system of the present ^ V^^,^^^ site ^ to collect 

pTa 4 is a block diagram of the structure memory of P^^Pj^ ^«"*!^ J[^°"; peripheral devic«i 18 19, 20 

the graphics subsystem of FIG. 2. 35 21, 22. The penpheral repeater box orgamzes the col- 

FIG 5 is a block diagram of the organization of a "^cted peripheral signals by packcUzmg the signals and 

node memory structure of a graphics data structure sending the packets to the h<»t central processing unit 

pursuant to the present invenUon. ^ ^^^^^^ Processor 13 The peripheral repeater 

FIG 6 b a block diagram of the BI bus memory map box 23 also receives packets from the host processing 

of the invention ^ ""^^ control processor 13, unpacks the data 

FIG 7 is an exploded view block diagram of the and channels the unpacked data to the appropriate pe- 

reserved I/O space of the block diagram of FIG. 6, ripheral device 18, 19, 20, 21, 22. For a more detailed 

FIG « is a block diagram of the graphic context and description of the input and output pre-processing func- 

traversal model for bitmap graphics processing. tions of the control processor 13 and the peripheral 

FIG. 9 is a block diagram of the bitmap root. 65 repeator box 23, reference should be made to co-pend- 

FIG. 10 is a block diagram of the bitmap graphics ing Application Ser. No. 07/085.097 entitled Peripheral 

context Repeater Box, filed on even dale herewith now U.S. 

FIG. 11 is a block diagram of the bitmap cell array. Pat. No. 4,905,232. 
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Moreover, the Aurora control processor 13 is advan- bufTer data from the rendering processor 36 to the pixel 
tageously operable to emulate a console for the Scorpio processor 35. As will be described in more detail below, 
host central processing unit 10. The consule emulation the rendering processor 36 is used in the three-dimen- 
is accomplished through the use of a serial data line 25 sional graphics process to render polygons, 
between the control processor 13 and the host central 5 The pixel processor 35 comprises siiteen identical 
processing unit 10. The Aurora control processor 13 processors which draw antialiased and depth-cued lines 
may therefore be used to run diagnostics and to debug using the endpoint and slope data produced by the del* 
the host subsystem without the need of additional ta/depth cue calculator 34 as well as the polygon rcn- 
equipment. For a more detailed description of the con* dering data provided by the rendering processor 36. 
sole emulation function of the control processor 13, tO The data from the pixel processor 35 is sent to a frame 
reference should be made to copending Application buffer 37 which comprises a 1024X 1024 pixel memory 
Ser. No. O7/084»930 entitled Console Emulation for to contain the pixel image generated for the system 
Graphics Worksution, filed on even date herewith now monitor 38. The frame buffer 37 provides a 1024 x 864. 
U.S. Pat, No. 4,903,218. 60 hz noninterlaced, rastar-scan display format. 

Pursuant to the preferred embodiment of the inven- 13 A video controller 39 receives the output from the 
tion, the graphics syfosystem 17 comprise a Shadowfox frame buffer 37 and converu the digital dau to an ana> 
graphics card set marketed by the Evans & Sutherland log signal to drive the monitor 38. In the preferred 
Computer Corporation. The primary function of the embodiment, the monitor 38 comprises a Digital 
graphics subsystem 17 is to store graphics data stnic- VR290-DA/D3/D4 nineteen inch color monitor hav- 
tures built by a plurality of application programs resid- 20 ing a 1024 x 864 pixel image area. The video controller 
ing in the central processing unit 10 and to process, 30 also contains a window look up uble to determine 
manipulate and display the graphics data structures, as the video format for the display and a color look up 
will appear. Referring to FIG. 2, the Shadowfax graph- table of color values to define the red, green and blue 
ICS card set includes a structure memory 26 interfaced components of the pixels. A graphics data bus 40 is 
with the control processor 13 by the local 11 32 bus 16. 25 provided to interface the video controUcr 30 and the 
As will be described in more detail below, the structure various other components of the graphics subsystem 17, 
memory 26 comprises a 4-Mbyte memory to store the as illustrated in FIG. 2. 
graphics data structures built by application programs . 
in the host central processing unit 10. Subsystem Mappmg 

An asynchronously operational structure walker 27 is 30 Subsystem mapping refers to a technique utilized in 
interfaced with the control processor 13 by. the II32 bus the present invention to allow the host processor 10 to 
16 and with the structure memory 26 by a structure directly access local RAM in the control processor 13, 
memory bus 28. The structure walker 27 is a special- structure memory 26 and various registers in the graph- 
purpose, 32 bit, bit-slice microprocessor that traverses ics subsystem 17. These components are directly 
the graphics data structures stored in the structure 35 mapped into host system virtual memory. Subsystem 
memory 26 on a continuous basis and sends the graphics mapping is highly advantageous in the operation of the 
data to the graphics pipeline processor 29 through line system of the present invention, which is a *'data- 
30. driven'* machine, as will appear. 

In accordance with the design and mode of operation In a conventional system^ the method that is used to 
of the Shadowfax graphics subsystem, the graphics 40 access hardware external to a CPU is through the use of 
pipeline processor 29 organizes the data received from a device driver. A device driver is a program which is 
the structure walker 27 into packets and performs specifically tailored to handle communications between 
graphics transformations, matrix multiplication, clip- a host CPU and a specific device, i.e., memory^ disk 
ping, perspective division and viewport mapping. Ac- unit, tape unit, etc. Thus, when the CPU wishes to 
cordingly, the graphics data structures, as processed by 45 access external device memory, it invokes a device 
the graphics pipline processor 29, are transformed from driver which either loads device memory directly 
the data structure world space data as implemented by through the use of registers or sets up a direct memory 
a user through an application program in the host cen- access (DMA) operation. For DMA. the driver locks 
tral processing unit 10 into displayable screen space down the user*s data into physical memory (DMA 
data relative to the physical dimensions of the screen 50 hardware requires that the data be locked into physical 
upon which the object is to be displayed. memory), sets up source and destination addresses, and 

Apair of data taps 31 ,32 examines each command and then invokes DMA hardware to get the information 
data packet received from the output of the graphics transferred from source to destination, 
pipeline processor 29 to determine whether to send the Generally, this DMA approach is very acceptable, 
packets further down the pipeline or to send the packets 55 However, in a data-driven machine such as the present 
into a graphics data manager 33, which forwards the invention, the cost of such approach would be prohibi- 
packets to the appropriate destinations. For example, X, tive. In the present grap^xics system, the host central 
Y, Z and color data packets are sent directly to a delta/- processing unit*s main function is to send commands to 
depth cue calculator 34 for calculation of line slope, the graphics subsystem 17. This would require the host 
adjusted end points and status (lags which describe the 6C central processing unit 10 to utilize DMA hardware for 
orientation of a line. Color data and Z data are mixed almost every operation it performed. Thus, it was with 
with background colors to determine relative red. green this problem in mind that subsystem mapping scheme 
and blue values. The delta/depth cue calculator output was devised. 

is sent to a pixel processor 35 for calculations in line The host central processing imit 10 shares the BI bus 
drawing algorithyms. The graphics data manager 33 is 65 15 with system memory 11 and the control processor 13 
used to load all valid draw commands for loading into (See FIG. 1). The control processor's local bus is the 
the pixel processor 35 and funher operates to buffer II32 bus 16. On bus 16 are the local control processor 
pipeline commands to a rendering processor 36 and to RAM (I Mbyte), local registers, and components of the 
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graphics subsystem 17 including structure memory 26, 
structure walker 21, graphics pipeline 29, graphics data 
manager 33 and rendering processor 36, pixel proces- 
sors 35 and the frame buffer 37. Note that not all the 
above components arc f^yslcally connected to the II32 5 
bus (Sec FIG. 2). The subsystem mapping scheme per- 
mits the host centra] processing unit 10 to directly ac- 
cess II32 bus components. 

To accomplish the direct access, the II32 bus 16 com- 
ponents are mapped into the reserved I/O space of the It* 
BI bus memory map. FIG. 6 illustrates the BI memory 
map and FIG. 7 sets forth the details of the reserved 
I/O space of the memory map of FIG. 6 where the 
components are mapped. Upon system initialization, a 
device driver of the host central processing unit 10 is 
invoked to perform the mapping. The first step it per- 
forms is to set up two mapping registers in the control 
processor 13. The mapping registers themselves are 
mapped into the host virtual address space by the opcr- 
ating system. The first register. SADR. reflects the 
starting address of the reserved I/O space in the BI 
memory map which is 20B00000 HEX. The second 
register, EADR, reflects the ending address of the re- 
served I/O space in the BI memory map which is 
22000000 HEX. This is accomplished by the device 
driver simply writing the start and end address into the 
respective registers. The control processor 13 micro- 
code relocates its own local RAM to be within this 
address range. Once this step is performed the physical 
mapping has been accomplished. 

The next step that the host device driver performs is 
to map each II32 component (control processor RAM, 
structure memory 26 and graphics subsystem 17 regis- 
ters) into the host's system virtual address space (S0). 35 
This step is required because host software is incapable 
of specifying physical addresses due to the inclusion of 
memory management (MM) hardware on the host cen- 
tral processing unit 10. This hardware is always running 
and screening addresses output by the host central pro- 40 
cessing unit 10. Each address is assumed to be a virtual 
address, therefore, the memory management hardware 
will always try to perform a level of translation with 
that address to create a physical address. The level of 
translation depends on whether the address is a system 45 
virtual address or a process virtual address. This distinc- 
tion is important because each goes through a different 
translation table and translation mechanism. Process 
virtual addresses arc process specific and, if used for 
purpose of present invention, every process would have $0 
to map to the memory itself. This would give every 
process 4 MBytes of virtual address space added to its 
own address space. Thus, in accordance with the pres- 
ent invention, by selecting the II32 bus mapping to be 
system virtual addresses, every process on the system 55 
can have access to this bus without wasting memory 
resources. This also reduces the complexity of computa- 
tions used to determine physical addresses referenced 
by the graphics subsystem. 

The last step that the host device driver performs is to ec 
unprotect S0 pages that contain the 1 132 bus compo- 
nent's virtual addresses. By unlocking these pages, any 
process on the system can access this system virtual 
address space. Generally, S0 pages contain operating 
system software and data that not every process can 65 
access. If an SO page is locked, the only way to access 
these virtual addresses is through the use of system 
calls. This would add more complexity to the system 
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and increase the overhead. Thus by unlocking the S0 
pages, the use of system calls are eliminated. 

After the host device driver has performed the steps 
described above, the mapping is complete. Now each 
process has direct read/write access to any of the 
mapped II32 bus components because these compo- 
nents are directly mapped into the host*s virtual mem- 
ory. Each process can treat these components as its own 
local memory. Therefore, the need for the use of direct 
memory access hardware, device drivers or operating 
system calls is eliminated. 

MEMORY AND SOFTWARE ORGANIZATION 

From the above description, it should be understood 
that the graphics subsystem 17 operates essentially in an 
asynchronous mode determined by the asynchronous 
operation of the structure walker 27 which, as described 
above, controls the flow of data from the structure 
memory 26 to the other components of the graphic 
subsystem 17 through the continuous, sequential tra- 
versal of the graphics data structures. The entire data 
flow through the graphics pipeline is a function of the 
structure walker operation. As will be described in 
more detail below, the host central processing unit 10 
executes application programs to build graphics data 
structures in hierarchical node structures representative 
of the three dimensional objects to be displayed. The 
node structures are stored in the structure memory 26. 

CONDITIONAL NODES OF A GRAPHICS DATA 
STRUCTURE 

A graphics data structure consists of all the data 
which descrit>es an object and how it is displayed. A 
graphics data structure is a hierarchical collection of 
nodes and the paths that connect them. 

A node is a set of executable commands and data. The 
structure walker 27 traverses each node in order, fol- 
lowing one or more pointers in each node which link 
the node to the rest of the data structure. As it traverses 
the node, the structure walker 27 extracts the com- 
mands and data and sends them down the graphics 
pipdine, where they eventually result in the display of 
the object defined by the data structure. 

The data structure exists in a graphics environment 
deflned by a graphics context which will be described in 
more detail below. The graphics context is connected to 
the system data structure through a virtual root node. A 
virtual root node is simply the top-most node created by 
the user stemming fix>m the graphics context that was 
created by the system as shown in FIG. 13. 

While building a data structure, the nodes that form 
the data structure offer a wide range of functions i.e. 
from describing gr^hics primitives to controlling tra- 
versal flow. Nodes are linked together in groups or 
structures, by first calling the structure graphics routine 
(SGR): 

SORSBEGIN-STKUCTURE (cootcxt); 

and then calling the routines that create the node, and 
ending the sequence with the routine SGRSEND.S- 
TRUCTURE (context, handle). The result is that the 
pointers link the nodes together thus permitting the 
structure walker 27 to traverse the nodes in their cor- 
rect order as described below. 

There are six node classifications for creating data 
structures. The first three being: 
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Primitive nodes— Contain graphics data for vectors, each other. UnconditionaJ nodes reference a single sub- 
polygons and strings. structure with the option of returning to the higher- 
Attribute nodes— Control the appearance of graphics level structure when the structure walker 27 finishes 
primitives such as line color, line pattern, shading and traversing the referenced structure. FIOS. t4a^ give 
lighting. S examples of various kinds of references. Note that an 
Transformation nodes— Describe how data is viewed "K*\ "NR", or "B" in the right side of a reference node 
on the screen. Transformation nodes control the com- in FIOS. 14a-c indicates whether the reference is of the 
position of matrices for graphics transformation and restore. no-restore» or branch variety; in addition, a 
normal transformation, and for the viewpon. For exam* circle is placed on the main reference pointer for no 
pie, if a primitive node builds a cube, a transformation 10 restore references as an additional visual clue, and 
node can scale and rotau it to make a brick. nodes following a branch reference are shaded gray to 
The next three nodes are used to create advanced show that the structure walker 27 never traverses these 
graphics data structures. nodes. 

cMi-c wnrfccc shows a daU structure featuring a Call/Re- 

KtrfcKtiNcti JNUUt5> ,5 jj^^ displays a red circle with a blue 

Hierarchical structures are built with reference square. Because the reference node restores state, the 

nodes. A reference node instrucu the structure walker red line-color attribute does not affect the Une-color 

27 to uaverse another structure (referred to as a "sub- attribute set in the calling structure, 

structure" of the calling structure) before continuing FIO. 146 shows a data struaure featuring a condi- 

with the traversal of the structure containing the refer- 20 tional Test/No Restore node which displays either a 

ence node. Reference nodes operate in three modes: blue or a red square, depending upon whether the oper- 

restore, no restore and branch. The ref— mode parame- and tested by the Test/No Restore node is true or false, 

ter of the routine that creates the node defines the mode. Because the reference node does not restore state,' the 

These modes control the manner in which changes to line-color attribute set in the referenced structure does 

the hierarchica] graphics state affect the traversal of 25 affect the color displayed by the calling structure, 

other parts of the graphics daU structure. FIG. 14c shows a daU structure featuring a condi- 

»p<rm»i: vinnTr tyonsH Compare/Branch node which will display one of 

KC3iupn.t^ XVI referenced substructures, depending on the 

A reference node set to restore mode instructs the values of the operands compared by the CompareA 

structure walker 27 to save the current graphics sute 30 Branch node. Note that diagrams of substructures that 

such as the current transformation matrix, current attri- cannot fit on the page are represented by labeled 

bute settings, etc. on a stack before traversing the refer- frames. 

enced substructure, then to restore that state when it has ccir-Krwcxrr xinr^cc 

finished traversing the substructure. As a result. ASSIGNMENT NODES 

changes in the hierarchical graphics state made in a 35 The assigiment nodes set up and manipulate the val- 

substructure do not affect the graphics state of higher ues (operands) that are tested by conditional refererK:e 

structures. nodes, permitting dynamic control of how a given con- 

NO-RESTORE MODE ditiona! reference node selects the path of traversal. The 

iNu-Kta t vjKt: w Kju^ nodes perform operations on data contained in structure 

A reference node set to no-restore mode redirects the 40 memory locations. The operations include move, logi- 

structure walker 27 but does not instruct the structure cal OR (set bits), logical AND NOT (clear bits) add, 

walker to save the hierarchical graphics-state and re- subtract, logical XOR. 

store it upon returning to the reference node. This mode wr^ixcc 

is useful in at leasct two situations: When you arc sure SFtCIAL PURPOSE NODES 

that a referenced substructure will not change the 45 The special purpose nodes allow you to build custom 

graphics state and you want to optimize traversal per- nodes, use the same data at different places in the struc- 

formance, and when you want changes in graphics state ture, and store uni^sed data. This saves both structure 

at a lower hierarchical level to affect the traversal of an memory space and editing time. Three special purpose 

equal or higher level of the data structure. nodes are provided; a data node, a generic node, and an 

nn ANru Mnnp ^ indirect node. These nodes can provide increased flexi- 

tfKAiN^n MUi^t ^jjjj^y allowing the application to tailor a data struc- 

As with the restore and no-restore modes, a reference ture for its own needs, 

node set to branch mode redirects the structure walker Data nodes are provided to contain application data 

traversal. However, when the structure walker 27 fin- in fields which arc reserved for the application. The 

ishes traversing the referenced substructure, it does not 33 structure walker ignores data in the data node, and 

return to the reference node; as a result, there is no need follows the next pointer. 

to save or restore the graphics state. Branch reference The generic node contains commands and data that 

mode is usually used with conditional reference nodes go to the pipeline. The structure walker 27 does not 

which select among two or more substructures. It is process information in a generic node, but passes this 

similar to the **GOTO** statement in a programming 60 node to the graphics subsystem 27 without recording 

language. changes in the subsystem state. Generic nodes can 

Reference nodes are of two types: conditional and change the state of the graphics subsystem, but the 

unconditional. Both node types can perform restore, structure walker does not restore changes made this 

no-restore, and branch references. Conditional nodes way. 

select one among two or more alternate traversal paths 65 The indirect node provides the ability to reference 

depending on the value of one or two operands. For data in one mode from another node in the data stnic- 

example, one type of conditional node compares ture. For example, an application can define a node 

whether operands are equal to, greater than, or less than containing line color data and use indirect nodes to 
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reference the infoimation in the indirect node. Thh 
saves memory and allows changes to the color deflni- 
tioDS without editing many nodes throughout the struc- 
ture. Any primitive, attribute, and transformation oper- 
ations can be done using indirect nodes. 

Advanced graphic data structures are created by the 
routines shown in Table 1. 

TABLE 1 



four access modes described in Table 2 and are the 
subject of the present invention. 

The access modes are specified by constants set in the 
mode, model or mode 2 parameters (depending on the 
node type) of the routine that creates the node. The 
access modes tell the system how to interpret the opera- 
tional spedfiei (opspec) parameter argument of the 



AdvMiced Graphic Dau Smicturt Routmet 



SGR Parameter 



1. SORSBEOIN-STRUCnJRE 

2. SGRSEND-STRUCTURE 

3. SGRSCALL 

4. SGRSTEST 



3. SOR$TEST_AND-CLEAR 

6. SGRSCOMPARE 

7. SORSCASE 

8. SGR$TEST_SET 

9. SGRJTEST_CLEAR 

la SGRJMOVE 

11. SGR$MOVE-B1-OCK 

12. SGRSMOVE_MASK 

13. SORSSET-BITS 

14. SGR$CLEAR_B1TS 
11 SORSADD 

16. SGRSSUB 

17. 5GRSXOR 

18. SGRSGENERIC 

19. SGRSINDIRECT 

20. SGRSINDIRECT 

21. SGRSDATA 



oooicxl 

comexu handle 
corn ext. reference— mode, 
reference—handle, handle 
context, refercnccfDodCi mode, 
opspec, (nie_hand)e. false 
handle, handle 

context, refercnoc-JBode, mode, 
opupcc, tntc— handle, fabe 
handle, handle 

context, reference— mode, model. 
inodc2, opspec2, less— handle, 
equal— handle, greater— handle, 
handle 

context, rererencc— mode, mode, 
opspec, count, otherwise 
handle, case^handles, handle 
context, rererencc— mode, model, 
opspec 1, mode2, opspec2, true 
handle, fahe— handle, handle 
context. reference.-mode, model, 
opspec I. niode2 op^ec2, tnie 
HANDLE, FALSE-handle. handle 
context, model, opspec 1, roode2. 
opspec2, handle 
context, uze, model, opspec 1, 
model, opspec2, handle 
context, mask, model, opspec 1, 
mode2. optpecl. handle 
contexL model, opspec 1. mode 2, 
opspcc2, handle 

context, model, opspec 1. inode3. 
opfipec2, handle 

context, model, cpspecl, roode2, 
opspecZ, handle 

context, model, cpspecl. inode2. 
opspec2, handle 

context, model, opspec 1, mode2, 
opspecl handle 
context, size, data, bamlle 
context, u>— handle, handle 
context, lo— handle, handle 
context, size, data, handle 



The use of conditional nodes provide the user with 
greater flexibility in the creation of advanced data struc- 
tures. Referring to Table 2 above, conditional nodes are 50 
created by calling routines 4-9 assignment nodes by the 
routines 10-17 and special purpose nodes by the rou- 
tines 18-21. 

CONDITIONAL REFERENCE NODES 53 

Conditional reference nodes redirect the traversal 
path of the structure walker 27 based upon either a 
true/false test or a value comparison. Based on the 
outcome of the test, the conditional reference node 
instructs the structure walker 27 to follow a predeter- 
mined traversal path associated with the test result. 

The lest performed by the conditional reference 
nodes use values stored in one or two operands (de- 
pending on the node type) in the node. The value of 
these operands are set by the manipulations of the as- 65 
signmcnt nodes thus permitting dynamic control of how 
a given conditional reference node selects the path of 
traversal. These operands are retrieved by use of the 



routine. The model parameter specifies the access of 
opspec 1, and mode 2 specifies the access of opspec2. 

TABLE 2 



Constant 



Operand Access Modes 
Mode Descnption 



SGRSK_1MMEDIATE 



SGRSlC—ABSOLirrE 



60 



SGRSK-RECISTER 



The operand is the current 
value uorcd as the operand 
specifier (opspec) a command 
paraLmcter tn the node. 
The operand is contained in the 
strucittre memory virtual 
address stored as the operand 
specifier in (he node. 
The operand b contained in one 
of three registers numbered 
(0-2). These registers are 
spedal locations in structure 
memory which can be saved and 
restored as part of the 
hierarchical graphics sute. 
All three regtsten can be used 
lo store an operand, but 
register 0 must be reserved for 
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COfUUfll 



Operind Accoi Modes 

Mode Dcscripiion 



SORSK-DISPLACEMENT 



use as a b«s»-«ddreu register 
when displacemem mode it used. 
The opermod is located in the 
ttniciure memory vinual 
address obtained by adding tbe 
valne stored in the operand 
■pedAer to the contenu of 
regffter 0. 



10 



30 



35 



40 



Tbe test perfonned by the conditiomJ reference node 
uses the value of the operand at the time of traversal; 
this may be the operand passed to the node*bui]ding 13 
routine when it was caOed, or an assignment node may 
have changed the value of the operand as dmiled be- 
low. 

Tbe Operand access modes are important in the use 
of assignment and reference nodes. By use of the access 20 
modes» assignment nodes can create additional data or 
general data in the structure memory. The reference 
nodes can then be made to branch according to the data 
created. The use of special purpose nodes allows the 
data to be sent to the graphics subsystem 17. In this way, 23 
the data structure can in effect write a "subprogram** 
and execute it during the traversal of tbe structure. This 
provides for a more general functionality as well as a 
more efHcient use of memory resources than present 
methods whereby conditional branching takes place on 
a fixed location such as a condition register. 

Examples of conditional reference and assignment 
nodes arc as follows: 

TEST 

•TEST-AND-CLEAR 
•COMPARE 
•CASE 
•TEST-SET 
•TEST-CLEAR. 

The test node is created by the routine: 
SGRSTEST (context, refcrcncc—mode. mode, op- 
spec, true handle, false— handle, handle) 

This node performs a simple true/false test on an 
operand and directs the structure walker to traverse one 
of two substructures depending on whether the results 43 
of the test is true (nonzero) or false (zero). The value of 
the operand remains unchanged. 
The test— and— clear Node is created by the routine: 
SGR$TEST_AND CLEAR (context, referen- 
ce—mode, mode, opspec, true— handle, false— han- 30 
die, handle). 

This node performs a true/false test similar to the test 
node. It first tests the value of an operand, then sets the 
value of the operand to zero (false). Because it clears the 
operand (that is, sets it to a false condition), on subse- 33 
quent traversal this node would direct the structure 
walker 27 down the path associated with a true condi- 
tion only if the operand were reset to true once again. 

The compare node is created by routine: 

SGRSCOMPARE (context, reference— mode, 60 
model, opspecl. modeZ, opspec2, less— handle, 
equal- handle, greater handle, handle) 

This node performs a test on two operands to deter- 
mine which, if either, is greater, and directs the struc- 
ture walker to traverse one of three substructures, de- 65 
pending on whether the first operand is less than, equal 
to, or greater than the second operand. The operands 
remain unchanged. 



The case node is created by the routine: 
SGRSCASE (context, reference^mode, mode, op- 
spec, count, otherwise— handle, case— handles, han- 
dle) 

This node tests the value of an operand and directs 
the structure walker to traverse a substructure assigned 
to that value; if the value of the operand is not associ- 
ated with substruture, then a dcfalt substruture is tra- 
versed. The operand remains unchanged. This node 
allows the selection of a number of traversal paths, 
depending on the value of the operand in the node. 

The test-set and test— clear Nodes are created with 
the rou tines : 

SGR$TEST-SET (context, rrferencc mode, 

model, ops.pecl, mode2, opq>ec2. true— handle, 

false handle, handle) 
SORSTEST-CLEAR (context, reference mode, 

model, opspecl, mode2, opspecl, true— handle, 

false— handle, handle). 
These nodes allow the performance of mask-like tests 
to determine which parts of the graphics data structure 
will be traversed. The test— set daermines if the bits 
which are set in the first operand are also set in the 
second operand. If the test result is true (that is. if the 
logical AND of the two operands is equal to the first 
operand), then the fust substructure is traversed; if false, 
the second substructure is traversed. 

The test— clear determines if the bits which are clear 
in the first operand are also clear in the second operand. 
If the test result is true (that is, if the logical AND of the 
two operands is equal to 0), then the first substructure is 
traversed; if false, the second structure is traversed. 

For instance, a mask could be store in register 1 
which represents whether certain features are ^'en- 
abled" or ••disabled." A test-set node could be used to 
test whether a feature was enabled and, if so, direct the 
structure walker to traverse the appropriate substruc- 
ture. 

ASSIGNMENT NODES 

Assignment nodes provide additional flexibility in the 
use of conditional reference nodes by modifying their 
operands as a result of data structure traversal. In other 
words, the condition to be tested by the conditional 
reference nodes can be different at each traversal, de- 
pending on how assignment nodes are used to modify 
their operands. 

Assignment nodes perform arithmetic or bit opera- 
tions on the operarKis used by conditional reference 
nodes. The following are assignment nodes: 

•MOVE 

•MOVE-BLOCK 

•MOVE-MASK 

•SET-BITS 

•CLEAR-BITS 

•ADD 

•SUB 

•XOR. 

The move node is created by the routine: 
SGRSMOVE (context, model, opspecl, modc2, op- 

spec2 handle). 
This node performs a longword move operation, 
from the location described by opspecl to the location 
described by opspec2. 
The move—block node is created with the routine: 
SGRSMOVE-BLOCK (context, sire, model, op- 
specl, mode2, opspecl, handle). 
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This node pcfforms a move operation on a block of 
longwords indicated by the site parameter, from the 
location described by opspccl to the location described 
by opspec2. 

The move—mask node is created with the routine: 3 

SGR$MOVE-MASK (context, mask. mode2. op- 
spec2, handle), 

The node sets the bits specified by the mask parame- 
ter to the same values in the second operand as their 
corresponding values in the first operand. 10 

The set— bits node is created with the routine: 

SGRSSET—BITS (context, model, opspecl. model, 
opspec2, handle), 

This node performs a logical OR operation, setting all 
the bits in the second operand which are set in the first. 15 

The clear— bits node is created with the routine: 

SGR$CLEAR_BITS (context, model, opspecl. 
mode2 opspecl, handle)* 

This node performs a logical AND NOT operation, 
dcaring all the bits in the second operand which are set 20 
in the first. 

The add node is created with the routine: 

SGR$ADD (context, model, opspccl. modc2. op- 
spec2. handle). 

This node performs a signed longword addition of 25 
operand 1 and operand 2. The result of the addition is 
stored in the second operand. 

The sub node is created with the routine: 

SGRSSUB (context, model, opspecl. modc2. op- 
spccl, handle). 30 

This node performs a signed longword subtraction, 
subtracting operand 1 from operand 2 and storing the 
resuh in the second operand. 

The xor node is created with the routine: 

SGRSXOR (context, model, opspccl. modc2, op- 35 
spec2, handle), 

This node performs a logical XOR operation using 
the two operands and storing the result in the second 
operand. Note that if all the bits in the second operand 
are set, a logical NOT is performed. 40 

Examples of special purpose nodes are given below. 

The routines that build special-purpose nodes in- 
crease the flexibility and efficiency of the graphics data 
structure. There are three nodes as follows: 

•Generic 45 

•Indirect 

'Data. 

The generic node is created by the routine: 
SGR5GENERIC (context, sire. data, handle). 
The generic node provides the means of sending 50 
commands or data, or both, through the graphics pipe- 
line; in effect, creating a custom node. The commands 
that are used should not affect the hierarchical graphics 



state. 



55 



The indirect Node is created by the routine: 
SGR5INDIRECT (context, lo-handle, handle). 
The indirect node references data in another node. 
An application may insert indirect nodes that reference 
predefined data. The routine inserts the node type of the 
referenced node into the indirect node being created, as 60 
well as a pointer directing the structure walker to tra- 
verse the data contained in that node. This creates a 
node identical to the referenced node, but located in a 
difterenl part of the graphics data structure. This rou- 
tine is useful in building attribute tables. This saves 65 
memory, and limits the number of changes when edit- 
ing. 

The data Node is built by the routine: 



SGRSDATA (context, size, data, handle). 

The data node is used for storage, or to hold dau to 
be used by the application program. During structure 
traversal, the structure walker 27 passes over data in 
this node, but follows the next pointer. 

The primary function of the structure walker 27 is to 
accurately traverse the nodes of the data structures in 
the proper sequential order and to process each node 
type correctly. The processing function of the structure 
walker 27 involves execution of node conunands relat- 
ing to further traversal of the nodes of the structure or 
conditional branching to alternative node branches in 
the node structure and the sending of the data and com- 
mand information contained in the traversed nodes to 
the graphics pipline processor 29 for processing, as 
described above. 

SOFTWARE ORGANIZATION 

Referring now to FIG. 3. there is illustrated a block 
diagram of the software organization of the graphics 
system of the invention. An application 100 contains 
requests relating to the building of graphics data struc- 
tures. Many applications 100 are present in the host 
central processing unit 10 to build multiple graphics 
data structures for manipulation and display by the 
graphic subsystem 17. In the preferred embodiment, the 
X Window System is implemented to perform the win- 
dowing and bit map graphics requests contained in the 
application program 100. The X window system is fully 
diescribed in publications published by the Massa- 
chusetts Institute of Technology such as XUb-C Lan- 
guage X Interface Protocol Version 11 by Jim Getty s, Ron 
Newman and Robert W. Scheifler and X Window Sys- 
tem Protocah Version 11 Beta Test by Robert W. Schei- 
fler. These publications are available to use. copy, mod- 
ify and distribute for any purpose without fee. Informa- 
tion on the X Window System may be obtained from 
the Massachusetts Institute of Technology Laboratory 
for Computer Science, 545 Technology Square, Cam- 
bridge, Mass. 02139. 

The X Window System is based upon a client-server 
model. The application 100 is the client which accom- 
plishes its work by communicating its requests to a 
server process 101. The server 101 performs the re- 
quested function and returns a status to the client appli- 
cation 100. The major components of the X Window 
System are an X protocal 102, the server 101 and an 
XLib 103. 

The X protocol 102 defmes a model for conmiunica- 
tion between a server 101 and a client 100, and also 
defines the model for the graphics subsystem 17. The 
model consists of several objects which interact in spec- 
ified ways. The most fundamental object is the window, 
a rectangular array of pixels which may or may not be 
(partially) visible on the monitor 38 at a given time. 
Windows are in a hierarchy: in other words, windows 
may have sub-windows.' When a sub-window is dis- 
played, it will be clipped against its parent. The monitor 
is the root of the hierarchy. Each window has a unique 
ID, an optional property list, and may be manipulated 
by a process 100 other than the creating process 100. 
The X protocol 102 neither imposes nor encourages 
limits on the number of windows in existence O e. win- 
dows are "cheapo*)- Other objects defined by the X 
protocol 102 mclude 

Color Maps: associations between pixel values and 
colors 

pixmaps: a rectangular array of pixels 



06/17/2003, EAST Version: 1.04.0000 



tiles; B special kind of pixmap used to fill regions and 

define cursors 
polylines: a set of related points which are displayed 

in a window according to specified criteria 
(glyph) fonts: a set of bitmaps which correspond to S 

alphanumeric characters (includes proportional 

fonts) 

The X protocol 102 also defines a number of events. 
These events are detected by the server 101 as, e.g., 
inputs received from peripheral devices via the control 10 
processor 13 and peripheral repeater box 23 (see FIO. 3) 
and are passed on to clients 100. Examples of events are 
Exposure events: part of a displayed window which 
was previously occluded has now been uncovered 
Keyboard events: a key on the display has been IS 
pressed 

Button Events: a button on a pointing device (e.g. 
mouse 20) has been depressed. 

Clients 100 only receive notification of evenu in 
which they have explicitly expressed interest. Events 20 
are maintained in a time-ordered queue, and can be 
received by clients 100 either synchronously or asyn- 
chronously. 

The X Server 101 mediates communication between 
client applications 100 and the graphic subsystem 17. 23 
Each client 100 establishes a connection to the server 
101 via a communications protocol. A client 100 will 
send commands to a server 101 to perform functions 
such as drawing into a window, loading fonts, manipu- 
lating the color map, expressing interest in certain 30 
events, etc. The X Server 101 will then perform the 
requested functions, by, e.g., sending commands to the 
graphics subsystem 17 via a node in the structure mem- 
ory 26. 

A server 101 is always located on the same machine 35 
as the monitor 38. It is possible for there to be more than 
one server per machine, and for a server to control 
more than one monitor 38. Each monitor 38, however, 
may be controlled by at most one server. 

The server 101 provides a device independant (DDI) 40 
program which interfaces with a device dependant 
(DDX) program for communication from the X Win- 
dow system to the specific system of the invention upon 
which the windowing system is operating. With respect 
to the present invention, the most significant feature of 43 
the DDX is the three dimentional display context func- 
tions of the traversal control implemented through a 
display manager 106 in the windowing server 101 to 
connect a window dcfmed by a client application 100 to 
the three dimentional graphics structure built by the 30 
client application 100 in the structure memory 26, as 
will appear. In this manner, a three dimensional func- 
tionality is merged into the X Window System. 

Xtib 103 is the Client's interface to an X Server. It is 
a procedural interface which corresponds to the func- 39 
tions provided by the underlying X protocol 102. Thus, 
there arc calls to create windows, draw into them, etc. 
Since Xlib is a procedural interface, it is designed to be 
called from higher-level languages. 

A window manager 104 is an application which im- 60 
plements a human -workstation interface. It typically 
provides a user with the ability to create, move, resize, 
iconify, and destroy windows. These actions are indi- 
cated by using the mouse 20 as a pointing device, in 
conjunction with button clicks and keyboard hits. Al- 65 
though the X protocol 102 does not specify any one 
window manager, there are currently several from 
which to choose. X provides the necessary features for 
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a customized window manager implementation. This 
means that a window manager is not necessary for X 
applications to run and it is possible to have multiple 
window managers (not at the same time on the same 
display, however). 

A graphic package may be layered on top of the X 
Window System, as, for example, a GKS o/b package. 
In the present invention a graphics package is used for 
two dimentional displays through bit map graphics. 
Indeed, the X Window System was developed for use in 
coimection with bit mttp graphics systems. The bit map 
graphics contexts and command queues are processed 
by the rendering processor 36, as will appear. 

Pursuant to the invention, three dimensional graphics 
data structures are built by (he application clients 100 
directly through structured graphics routines 105 
(SGR) which are provided in the host subsystem. The 
applications 100 utilize the various structured graphics 
routines 105 as required to build specific graphics data 
structures. The structured graphics routines execute 
routine requests nude by the application 100 and build 
appropriate tinked nodes in the structure memory 26. 
The following arc several examples of structured graph- 
ics routines which may be provided in the host subsys- 
tem for implementation of graphics data structures. 

EXAMPLE I 

SGRSBEGIN-STRUCTURE 

FORMAT 

SGR$BEGIN_STRUCTURE(contexi) 

ARGUMENTS 

context 

The identifier of the graphics context for this subrou- 
tine call. The context argument is the address of an 
unsigned integer that contains the identifier of the 
graphics context block. 

PURPOSE 

To begin a structure. 

DESCRIPTION 

A structure is a group of nodes linked together. After 
calling SGRSBEGIN-STRUCTURE, all nodes cre- 
ated with the same context are added to the end of the 
structure. No nodes are created by SGRSBEGIN—S- 
TRUCTURE. A structure is terminated by SGRSEN- 
D_STRUCTURE 

The information for linking nodes is stored in the 
graphics context referenced by the context argument, 
so it is possible to build multiple structures at the same 
time using multiple contexts. 

Calling SGRSBEGIN-STRUCTURE for a context 
which is not building a structure is an error. 

It may be desireable to begin each structure with a 
node that does nothing, such as a data node or a disabled 
node. This permits the structure to be referenced by 
multiple nodes and still permits replacement of the first 
true node in the structure. 

EXAMPLE 2 
SGRSCOLOR 

.FORMAT 

SGR$COLOR(contcxt, red, green, blue, color) AR- 
GUMENTS context 

The identifier of the graphics context for this subrou- 
tine call. The context argument is the address of an 
unsigned integer that contains the identifier of the 
graphics context block. 

red 
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The red intensity of the color. The red argument is 
the address of an unsigned longword in F— floating 
format that contains the value for red intensity. This 
value is in the range 0.0 (no intensity) to 1.0 (full inten- 
riiy). 

green 

The green intensity of the color. The green argument 
is the address of an unsigned longword in F— floating 
format that contains the value for the green intensity. 
This value is in the range 0.0 (no intensity) to 1.0 (full 
intensity). 

blue 

The blue intensity of the color. The blue argument is 
the address of an unsigned longword in F— floating 
format that contains the value for the blue intensity. 
This value is in the range 0.0 (no intensity) to 1.0 (full 
intensity). 

color 

The color longword returned by the routine. The 
color argument returns the address of an unsigned long- 
word that returns the value for color. 

PURPOSE 

To create a color word. 
DESCRIPTION 

This routine creates a color composed of red, green, 
and blue intensities. The format of a color word is 
shown in following scale. 

Color is passed as an argument to 
SGRSSET-BACKGROUND, 
SGR$SET-LINE_COLOR, and SORSSTATUS. 

RELATED ROUTINES 

SGRSSET-BACKGROUND 

SGR$SET_LINE_COLOR 

SGR$SET_SURFACE-COLOR 

SGRSSTATUS. 

EXAMPLE 3 
SGRSVECTOR 

FORMAT 

SGRSVECTOR (context, venex—format. edit— 
flags, count, vertex_array, handle) 
ARGUMENTS 
context 

The identifier of the graphics context for this subrou- 
tine call. The context argument is the address of an 
unsigned integer that contains the identifier of the 
graphics context block. 

vertex—format 

Flags declaring the format of the vertices passed by 
the vertex—array argument. The vertex— format argu- 
ment is an unsigned longword that contains the follow- 
ing flags: 



Rag 



Pcscription 



SGR$M_STATUS 

SGR$M_X_ 

SGR$M-Y 

SGRSM_Z 

SGRSM_W 



When set. each vertex in 
the uray conuint a 
ftUtus word. 

When let* each vertex in 
Uw array conuint a 
coordinate for x. 
When set each venex in 
the array contains a 
coordiaaic for y. 
When set, each vertex in 
the array contatns a 
coordinate for Z. 
When set, each vertex in 
the array coniains a 
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30 



33 



40 



45 



50 



53 



20 

-continued 



Flag 



Description 



coordinate for w. 



edit— flags 

Flags specifying how the routine will format the 
status words of itemized vertices as it stores them in the 
node. The edit— flags argument is the address of an 
unsigned longword that contains the fofiowing flags: 



Rag 


Description 


SGRSM-EDIT-POLYUNE 


When aet, cieatet default 




itattit words for itmixed 




venicea with separate 




draw mode. 


SOR$M-£DIT-S£PARAT£ 


When set creates default 




status words for itemiied 




vertices with polyline 




draw mode 



60 



65 



If neither DGR$M_EDlT-.POLYLINE nor 
SGRSM^DIT— SEPARATE is set in the edit— flags 
argument, the status words of itemized vertices are not 
changed and the status word must be filled in properly 
for each vertex. The edit— flags argument does not af- 
fect vertices without status words. 

count 

The number of vertices passed by the vertc]i-..Array 
argument. The count argument is the address of an 
unsigned longword. 

vertex..array 

The array of vertices defining the vectors to be 
drawn. The vertex— array argument is the address of an 
array of longwords; this array must contain the number 
of longwords equal to the value passed by the count 
argument multiplied by the number of vertex compo- 
nents indicated by the number of flags set in vertex— for- 
mat. For example, if vertex^ormat declares a 3D-with- 
status vertex format (by setting SGRSM—STATUS, 
SGR$M-X, SGR$M_Y» and SGR$M-Z in the ver- 
tex— format argument) and the count argument declares 
that the number of vertices is 10, then the vertex array 
must contain 40 longwords. Vertex components must be 
in the order status, x, y. z, w. All coordinates must be of 
the default floating-point format set in the graphics 
context. 

handle The identifier of the node created by this 
routine. The handle argument returns the address of an 
unsigned longword that contains the identifier. 

PURPOSE 

To create a vector node. 
DESCRIPTION 

This routine creates a Vector node. When this node is 
traversed by the structure walker 27, data is forwarded 
to the graphics subsystem 17 to draw the vectors to be 
displayed, as described above. In order to be visible the 
vectors must be properly transformed (for example, 
they must be within the clipping planes), have correct 
attributes (such as a color different from the back- 
ground color), and must not be obscured by polygons. 

Each vertex can have a status word and x, y, z, and w 
coordinates. The sutus word sets the draw mode and- 
/or itemized vector color is enabled. 



06/17/2003, EAST Version: 1.04.0000 



5,251,322 



21 

EXAMPLE 4 
SGRSX-ROTATE-MATRIX 
FORMAT 

SGR$X-_ROTATE-MATRIX(context, multi- 
ply^ontrol, angle, matrix) 
ARGUMENTS 
context 

The identifier of the graphics context for this subrou- 
tine call. The context argument is the address of an 
unsigned integer that contains the identifier of the 
graphics context block. 

Multiply— control 

Specifies how the matrix argument is to be inter- 
preted. The multiply— control argument is the address 
of an unsigned longword. Acceptable values are: 
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Constant 


Function 


SGRSK-REPLACE 


The nuirii arBuinent 




retuim the new nutrijt 




produced by this routine: 




Mjilhx iiew_nutriji 


SGRS K-PREMULTIPLY 


The matrix argument 




tuppiies a matrix to which 




the new matrix produced by 




ihi» roucioe i& 




prcimj]tif4)cd. The matrix 




argument then returns the 




nesuiiing matrix: 




Matrix New_matrix x 




matrix 


SORS K-POSTMULTIPLY 


The matrix argument 




lupphes a matrix to which 




the new matrix produced by 




this routine is 




postmulDplied. The 




matrix argument then 




returns the rcsuhing 




matrix: 




tnatrix matrix x 




nrw matrix 
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The angle of rotation in radians. The angle argument 
ts the address of a longword in F— floating format, 
matrix 

The x-rotation matrix created by this routine. The 
matrix argument returns the address of a 4x4 array of 
longwords in F—floating format containing the result 
matrix. The matrix is in row major order. 

PURPOSE 

To create an x-rotation matrix. 
DESCRIPTION 

This routine computes a rotation matrix to rotate 
about the x axis. The resulting rotation is angle radians 
clockuose as viewed from the -fx axis. The rotation 
matrix is returned in the matrix argument. 

Any number of additional routines may be stored in 
the host subsystem to enable an application process 100 
to bufld a graphics data linked node structure represen- 
tative of a three dimensional image in color for storage 
in the structure memory 26 and eventual traversal by 
the structure walker 27. The following is an example of 
a complete structured graphics routine library with the 
routines bsted by function: 

TABLE 1 
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30 
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5GR Primitive Routines 
Arguments 



angle 



40 



Primitive SGRs 
SGRtFOLYGON 



SGRSSTRING 

SGRSVECTOR 

Primitive Utility SGRs 
SOR$PLANE_EQUATK>N 

SGRSSTATUS 



context, vertcJuJbnnat. 
flags, planc^uation. 
count* venncarray, 
handle 

context, vertex—format, 
vertex, nagx, count, 
string, handle 
context, vertex_fonnat. 
edit— flags, count, 
vencx_AiT«y handle 

context, verux—format, 
negate, count, 
vertex_jUTay, 
planc—cqua t ion 
context, flags, color, 
status 



TABLE 2 

SGR Attribute Routines 



Arguments 



General Attribute Routines 




SGRSSETJACKGROUND 


context, color, handle 


SGR$SET_GEOMETRY_MASK 


context, enable—mask, 




disaMc— mask, handle 


SGR$SET«INTENSITY_RANOE 


context, minimam, maximum. 




handle 


SGRSS£T_LINE.COLOR 


context, color, handle 


SGR$SET_LINE_FILTER 


context. Alter, handle 


SGR$SET_1JNE_PATTERN 


context, flags, mitk. 




dot— mask, mask—bits, 




paneni_lei]gtb. 




fiU— color, handle 


SGRSSET— RENDERING-MASK 


context, enable— mask, 




doable— mask, handle 


Vector Anribute SGRs 




SGRSSET-.MARKER-TYPE 


context, glyph, handle 


SGR$SET_VECT0R-r>RAW_MODE 


context, draw— mode, handle 


Polygon Attribute SGRs 


SGRJSET_UGHT 


context, light— id* light. 




handle 


SORSSET-LIGHTING-STYLE 


context, style, handle 


SOR$SET«UGHT_MASK 


context, cii^c— mask. 




disable— mask, handle 


S0R5SET_SHADING_STyLE 


context, style, handle 


SGRSSET-SURFACE-COLOR 


context, side, color, 




handle 
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50R Attribute Routines 



Arguments 





conteit* side, properties. 




handle 


Strinjt Attribute SORs 




SORSDO-STRINO-CHARACTERS 


context, bcftdlc 


SGRSDO-STRING-MATRIX 


context, handle 


SGR$D0_STRING_POSmON 


contex, handle 


SGR$SET-STRlNO_FONT 


cootexi, flags* 




sparing handlf, 




process— handle, 
glyph— handles, handle 


SORSSET-STRING-SPACINO 


context, ipacing—vector, 
handle 


Attribute UtUity SOR 




SORSCOLOK 


context, flags, red. 




green. Mue. color 



TABLE 3 20 TABLE 3-co ntinue d 



SOR Rendering Routines SOR Rcpderinji Rentines 

Rendering SORs Argumento Rendering SORs Argitwcnts 

SGRSBEGIN RENDERING context, style, handle SGRSEND^REltfDERING context, handle 



TABLE 4 
SGR Tranifonnation Routines 



Arguments 



Matrix Cofnpoaiion SORs 
SGR ICONCAT—M ATRIX 

SGRSLOAD-MATRIX 

SGRSSUBSTITUEE_M ATR IX 

Modeling SGRs 

SGRSA-ROTATE-MATRIX 

SGRSSCALE-MATRIX 
SGRSTRANSLATE-MATRIX 
SGRIROTATE-MATRIX 
SGRSY-ROTATE-MATRIX 
SO RSZ-ROTATE—M ATRIX 
Viewing SGRs 

SGRSLOOK-AT_VIEW_MATRIX 
SGRSPOLAR_VCE\^'_MATRIX 



Prokctton SORs 

SGRSORTHOGRAPHIC_PR0J_MATRIX 



SOR$PERSPECTIVE_PRCJ_MATRIX 

String Matrix SORs 
SGR$SET_STRING_MATRIX 
GeneiaJ Matrix Utility SGRs 
SGR$COPY_MATRIX 

SGRSIDENTITY-MATRIX 
SGRJINVERSE-MATRIX 

SGRSMULTIPLY-MATRICES 

SGRSNORMAL-MATRIX 



context, flags, inatrix. 
nonnal_jnatrix. handle 
context, flags, matrix, 
normal— matrix, handle 
context, flags, matrix, 
tkonnal—matrix, handle 

context, multiply— control, 
angle, point], point2, 
matrix 

context, mtiltiply—xontrol. 

vectof , matrix 

context, multiply ^control, 

vector, matrix 

context, multiply—contrd. 

angle, matrix 

context, multiply— contrd, 
angle, matrix 

context, multiply— contnd, 
angle, matrix 

context, multiply— control, 
from, lo. up, matrix 
context, multiply—control, 
view— flag, point, 
disunce, azimuth, 
incidence, twist, matrix 

context, multiply— control, 
height, aspect, front, 
back, matrix 

context, multiply —control, 
angle, height, aspect, 
front, back, matrix 

context, matrix, handle 

context, from— matrix, 
to— matrix 
context, matrix 
context, matrix, 
inverse— matrix 
context, prematria, 
posttnatrix, result^inairix 
context, matrix, 
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SGR Tf^ntfonnatioii Routines 



Argumenis 



nonnal^nutrii 



TABLES 



Viewport SGR* 



SGR Viewport Routines 
Arguments 



SORSCONCAT-VIEWPORT 



SORILOAD-VIEWPORT 
SGRISUBSnrUTE- VIEWPORT 



context. Icft^bonom, 
right.uc^ handle 
conteit, left—bottom, 
right— top, handle 
context, lcft_bonom, 
right— top, handle 



TABLE 6 



SGRJBEGIN-STRUCTURE 
SORSEND-STRUCTURE 



context 

context, handle 



TABLE 7 



SGR Reference Routines 
Argiimentt 



Uncondition*! Reference SGR 
SGR5CALL 



Conditiotial Reference SGRs 
SGRJCASE 



SGRSCOMPARE 



ooniezt. reference— mode, 
reference— handle, handle 

cofiiexi, reference— mode 
mode, op&pec. count, 
otherwise— hand le, 
case— handles, handle 
context, reference— mode, 
model, opipecl, model, 
opspec2. less— handle, 
equal—handle, 
greater —handle, handle 



TABLE 7-continued 
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SGR Reference Routtnea 
Arguments 



SORSTEST 



SORSJEST— AND-CLEAR 
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SGRSTEST.CLEAR 



SGR Structure BuDding Routines 
Structure Building SGRs Arguments 



SGRSTEST-SET 
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Arithmetic and 
Assignment SGRs 
SGRSADD 
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5GRSCLEAR-BIT5 

SORSMOVE 

SGR5MOVE-BLOCK 

SGRSMOVE-MASK 



SGRSSET-BITS 
35 SGRSSUB 
SGRSXOR 



context, reference— mode, 
mode, opcpcc, trve_haadle, 



context, reference— mode, 
mode, opcpec, tfiit<4iand]e, 
fahe— handle, haadk 
context. rcfenDoc- 



model, opqsecl, model. 
c^pcc2, trucJiasdle, 
ftlsf htndir, handle 
context, refcreocc—iDode. 
model, opqtect, mode2. 
opspec2, true-handle 
falscJundle, handle 



contexu model, opspecl, 
model, opspecl, handle 
context, model, opspecl, 
model opspecl. handle 
context model, opspecl, 
mode 2, opspecl, handle 
context, size, model, 
opspecl, model, opspecl. 
handle 

context, Dusk, model, 
opspecl, model, opspecl. 
handle 

context, model, opspecl, 
model, opspecl. handle 
context, model, opspecl. 
model, opspecl, handle 
context, model, opspecl, 
model, opspecl, handle 



TABLE 8 



SGR Graphics Context Routines 



Arguments 



Graphics Context SGRs 
SORSCOPY-CONTEXT 
SGRSCREATE-CONTEXT 
Graphics Context Editing SGRs- 
Inquiry 

SCRSINO-DEF-BASE-GEOMETRY 

SGR$1NO-DEF_BLINK_PERIODS 

SGRSINQ-DEF-BUFFERINC-MQDE 

SGRSINQ^EF-DRAWABLE 

SGR$INQ-DEF-FIRST_P1CK 

SGR$!N0_DEF_FP-FORMAT 

SGRSINQ-DEF-HIT-BOX-LOCATION 

SGR$INQ_DEF_HIT-BOX-SIZE 

SGRSINQ-DEF-UNE-RLTER 

SGR$1N0_DEF_PATH_STACK 
SGR$iNQ_DEF-PICK_ID-STACK 
SGRHNQ-DEF-PICK-LIMIT 
SGRSINQ_J>EF_PICK_QUEUE 

SGR$INQ-DEF-REPEAT-PERIOD 

SOR$!N0«DEF_TRAVERSAL-ID 

SORSINQ-DEF-.TRAVERSAL-MODE 

SGR$INQ_DEF-UPDATE_MODE 

SGR$INO-DEF_VERTEX 

SGR fl NQ-DEF-VIRTU AL_ROOT 

Grapbics Context Edidag SGRs- 

Setting 

SGR$SET_DEF-BASE«0EOMETRY 



from— context, io.^context 
display, context 



context, geometry 
context, on, off 
context, mode 
context, drawable 
context, pick-number 
context, fp— fcHinat, 
fp— block— exponent 
context, hit— box— location 
context, hit_box— aixe 
context, filter— oumbcr, 
fQter- values 
context, path— size 
context, pick id tire 
context. pick-Jtmit 
context, I 



path^xe, pick id tirr 
ccmtext. period 
context, traversal— id 
context, modeflags 
context, update— mode 
context, vertex— 4d 
context, handle 



context, geometry 
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SOR Oraphict Contot RoutuiCT 

Arsuments 



SGR$SET_DEF_BLINK_PERIODS 

SGR$SET-J>EF_BUFFERINO_MODE 

SOR$SET_DEF_DRAWABLE 

SGR$SET-DEF-_FIRST_Piac 
SORSSET-J>EF_FP-FORMAT 

SORSSET_DEF.HIT_BOX_LjOCAT10N 

SOR$SET-DEF_HlT_BOX_SIZE 

SORSSET-DEF-UNE-RLER 

SGR$SET_DEF_PATH_STACIC 
SOR$SET-J>EF_PICK-JD_STACK 
SORSSET-DEF-PIOC-UMIT 
SOR$SET-J>EF_PICK-QUEUE 

S0RSSET-DEF_REPEAT-J>ER10D 

SGR$SET-DEF_TRAVERSAL-ID 

SGR$SET_DEF_TRAVERSAL_MODE 

SOR$SET_DEF-UPDATE-MODE 

SGR$SET_DEF„VERTEX 

SGRSSET_DEF_ VIRTUAL-ROOT 



context, on. ofT 
context* mode 
context, dnwftble, 
aitsch-jdcttch 
context, pick—inunber 
context, fp—fonxut, 
fp— block— exponent 
context, hH— box— location 
context, hit— box— tize 
dnwftblc, fUier— Buinbcr^ 
filler— v«]ues 
context, p«tb.jxize 
context. pick_«L.size 
context* pick—limit 
context, pick— xizc. 
path_xize, pirV id trrr 
context, period 
context, tnversaLJd 
context, modeJglagt 
context, opdstc-jnode 
context, vertex— 4d 
context, handle 



TABLE 9 
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SGR Traverxal Control Rouiinet 



Traveml Control SGRs 



Argomesits 



SOR$SADD-TO_QUEUE 
SGRSSQUEUE 

SGR$$REMOVE-FROM_QUEUE 

SGRSINQ-TRAVERSAL-STATE 

SGRSRELEASE-UPDATES 
SGRSREQUEST_TRAVERSAL 



TABLE 10 



Picking SORs 



SGR Picking Rouiinca 

Arguments 



SGRSCOMPUTE_PlCK-POINT 



context, node— picked, 
type, pidcvector, vert- 



TABLE 10-continucd 



Picking SGRs 



SGR Pickiuft Routinet 

Arguments 



context, queue— handle. 
Tirst— handle, last-Jiafidle 
context, rererence— mode, 
first— handle, current- 
handle, last—handle, 
handle 

cofitext, queue— handle, 
first— handle, last— handle 
context, traversal — type, 
wxitflag. state 
context 

context, trxvcrsal— type 
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SGRSCONCAT-PICIt-ID 
SGRSGET-PICK 
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SORSLOAD-PICK-ID 
SGR$PRINT_PICK 
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SGRSSUBSTITUTE-PICK-ID 



geom mat, user— vector 
context, identifier, 
handle 

context, max pmth— pairs, 

DUO— pick— ids, sutus, 
Dode— picked, type, index, 
p^k— vector, 
vert— geosD— mat, 
cum piiim— ret, path, 
oiim ifis ret, pick— ids 
oontextjdentifier, 
handle 

context, max— pathpoirs, 
max— pick-Jds, suius. 
DOde_picked, type, index, 
pick— vector, 
vert— geom— mat. 
nuni— paiis— ret. path, 
num— ids— ret, pick— ids 
context, ideniifier, 
handle 
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TABLE 11 



SOR Input Handling Routines 



Input Handling SGRs 


Arguments 


SGRSALLOCATE-DEVICE 


context, device 


SGRSCONNECT-DEVICE-TO-MAT 


context, device, baadlet 




geometf ic^operation, axis. 




matrix— operation, value- 




usage-JUg 


SGR$DISCONNECT_DEVlCE_ 


context, device. 


FROM-MAT 


handle 


SGRSSISPATCH-DEVICE-EVENT 


context, event 


SGRSHND—DEVICE 


context, display, device* 




type, unit, device— id[, 




iiBiss[, nDims]] 


SGRSFREE-DEVICE 


context, device 


SGRK3ET-J5EVICE-ATTR 


context, device attrBlock 


SGRGET-DEVICE-CHARS 


context, device, nBins, 




nDtms. ndevice. ncxtdevice 


SGRSGET-DEVICE- VALUE 


context, device. 




valueBlock 


SGR$SET-DEVICE-AST 


context, device, 




valueBtock. evcntcode. 




action, parameter 


SGRSSET-DEVICE-ATTR 


context, device. attrBlock 


SORSSET-DEVICE-LABEL 


com ext. device, label. 




count 
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TABLE ll-continued 



SGR Input H>ndling Routitwi 
Input Hindling SORs Argpingntt 

SGRSSET-DEVICE- VALUE context, device, 

valueBlocfc 



TABLE 12 



SGR Sinictufe Edtting Routiiie$ 



Argumenti 



Structure Topolopy SGRi 
SORSINQUIRE-XINKS 

SGRSINQUIREJIEFERENCE 

SGRSPOSTHX—NODE 

SaR$PREnX_KODE 

SOR$REPLACE_INDIRECT 

SGRSPREPLArF NEXT 

5GRIR£PLACE_NODE 

SGRSREPtACE-REFERENCE 

Node Editing SORs^lnquiry 
SORdNQUIRE-BITMASKS 

SGR SINQUIRE-CHARACTER S 



SCRSINQUIRE.COLOR 

SGRINQUniE_DEFAULT_VERTEX 

SGR$INQUIRE_FP_BLOCK_EXPONENT 

SCRHNQUIRE-INDIRECT 

SOR$INQUIRE_INTENSm_RANGE 

SGR$INQUIRE_LINE_nLTER 
SGRSINQUIRE-MATRIX 

SGR$1NOUIRE_NODE_ENABLE 

SGR$lNQUIRE-NODE_TYPE 

SGRSINQUIRE-OPSPEC 

SGR$INQUIRE_P1CK_ID 

S0R$INQU1RE-PLANE_EQUAT10N 

SG RSrNQUl RE-REF.COUNT 

SGR$INQUIRE_STRING_SPACING 

SGRSINQUIRE-USER-DATA 
SGRS1NQUIRE_USER_TYPE 
SGRSINQUI RE-USER-.TYPE 
SGRSINQUIRE- VERTICES 



SORMNQUIRE-VIEWPORT 

Node Editing SGRs-Replacement 
SGRSREPLACE.BITMASKS 



SGR$REPLACE_CHARACTERS 



SGRJREPLACE-COLOR 

SORSREPLACE-DEFAULT.VERTEX 

SGR$REPLACE_FP_BLOCK_EXPONENT 



context, handle. 

prev Juadfe, Dcxt-JuDdle 

context, handle, index. 

reference— handle 

context, handle, 

ncw^Jiandle 

context, handle, 

new— handle 

context, handle, 

indirect— handle 

context, handle, 

Dew_next— handle 

context, handle, 

new_hand1e 

context, handle, index. 

refercnccJiamlle 

context, handle. 

enable— bits, disable— bits 

context, handle. 

rirst—positfOQ, 

Uit—position. 

string_tize, resolt^count. 

rcsnh—string 

context, handle, color 

context, handle, venex_4d 

context, handle, 

fp— block— exponent 

context, handle. 

indirect —handle 

context, handle, minimuni. 

maximum 

context, handle, filter 
context, handle, flags, 
nuthx. normal—inatrix 
context, handle, onoff 
context, handle, node- type 
context, handle, 
opspec— id, opspec 
context, handle, 
identifier 
context, handle, 
plane— equation 
context, handle, 
result— syst en— count, 
result— user— count 
conteit. handle, 
spacing— vertex 
context, handle user— data 
conteit. handle, user— type 
context, handle, user^type 
context, handle, 
first— position, 
last- position, array— size, 
result— count, 

result— vertex array 

context, handle. 

left— bottom, right— top 

context, handle. 

enable— bits, disable— bits * 

context, handle, position, 

delete— count, 

insert— count. 

insert^tring. 

result— handle 

context, handle, color 

ccmtext, handle, vcncx— 4d 

context, handle. 
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SOR Sirucmre Ediling Routinci 

Argumem* 



S0RSREPLACE_INTENSITY_RANOE 

SOR$REPLACE-LINE-JILTER 
SGRSREPLACE-MATRIX 

SGRSREPLACE_NODE_ENABLE 
SORSREPLACE-OPSPEC 

SGRSREPLACE-PICK-JD 

SORSREPLACE-PLANE-EQUATION 

SGRSREPLACE_STRINO_SPAaNO 

SGRIREPLACE-USER-DATA 
SGR$REPLACE_USER_TYPE 
SGRSREPLACE- VERTICES 



SGRSREPLACE-VIEWPORT 



fp_block_ezpoi>cni 
cootMt. btitdle, miiuminn, 
maximum 

context. bindle» filter 
context, bandk, Oags. 
matrix, norma]_matrix 
context, haadle, onofT 
context, handle, 
opipcc— id, opspec 
contezt, handle. 
idcDtifler 
context, handle, 
planc^cquation 
context, handle, 
tpacing— vertex 
context, handle, t itcr ^di ta 
context, handle, tt»er_type 
context, handle, potitton, 
delete— count, 
insert— count, 
insert, verticea, 
retttlt— handle 
context, handle. 
>cft— bottom, right^top 



TABLE 13 



SGR Structttfc Memory Management Romincs 
Structure Memory 

Managcroeni SGRs Arguments 



SGR$DECREMENT_REF_COUNT 
SGR$lNCREMEKT-REF-COUXT 



context, handle 
context, handle 
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TABLE 14 



SGR General Purpose Routines 
General Purpose SGRs Argument 
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SGRSDATA 

SGRM3EKER1C 

SGRSINDIRECT 



context, lixc data, 
handle 

context, sixe, data, 
handle 

context. to_bandlc. handle 
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Referring now to FIG. 4. the structure memory 26 is 
illustrated in block diagram form. The structure memo- 
ry's main function is to store the "working copy" of the 
graphics data structures built by the application pro- 
grams 100 residing in the host central processing unit 10 
either through the structured graphics routines or the 
bit map graphics package layered on the X Window 
System. The memory is made up of an array of memory 
devices 200 which are implemented as 256K CMOS 
DRAMS» each with a minimum memory size of one 
megabyte. The array of memory devices 200 is arranged 
for a total of four megabytes of memory. A random 
access taken 200 ns and a static column mode is used to 
achieve sequential access of 100 ns per word. 

A structure memory bus 201 interfaces the memory 
devices with an 1132 Bus interface 202, a structure 
walker interface 203 and a rendering processor interface 
204 to provide data flow between the memory devices ^ 
200 and the host central processing unit 10 via the con- 
trol processor 13, the rendering processor 36 and the 
structure walker 27. respectively. The structure walker 
27 is a special purpose, 32 bit bit-slice processor pro- 
grammed to traverse the three dimensional graphics 
data structure nodes, as described above. For a more 
detailed description of the structure memory 26 and 
structure walker 27 components of the graphics subsys- 
tem 17 reference should be made to the Shadowfax 



Technical Manual published by the Evans & Sutherland 
Computer Corporation. 

Traversal Control 

In accordance with a significant teaching of the in- 
vention, a traversal control function is partitioned 
among the components of the host and graphics subsys- 
tems to accept requests for graphics structure traversals 
made by the several, competing application programs 
100 residing in the host control processing unit 10 and 
to subsequently schedule and dispatch such traversal 
requests. 

The traversal control functions are embodied in node 
control structures built in the structure memory 26 
which, when traversed* provide a traversal request 
mechanism and handle traversal scheduling, traversal 
monitoring and application synchronization. The con- 
trol structures function to place the graphics subsystem 
17 at the disposal of all the several applications pro- 
grams 100 residing in the central processing unit 10 such 
that each program views the graphics subsystem 17 as 
its own. The traversal control structures therefor coor- 
dinate traversal requests from the competing applica- 
tion programs 100 with the asynchronous operation of 
the structure walker 27 to maximize the processing 
capability of the graphics subsystem 17 and enable a 
multiple of application programs to be processed. 

Pursuant to the invention there are three basic tra- 
versal structures: a system control structure (SCS), 
three dimensional display contexts (3DDCs) and three 
dimensional graphics cohtexts (3DGCs). The system 
control structure is the top-level control for the struc- 
ture walker 27 and acts as the structure walker 27 oper- 
ating system. The display contexts defme the mapping 
of three dimensional images within viewports on the 
monitor screen defined by windows. The graphics con- 
texts provide all the graphics attributes and control 
information required to perform the traversals of graph- 
ics data structures including a connection to a comple- 
mentary display context. 

The control structures are interconnected by attach- 
ing a doubly-linked list of graphics contexts created by 
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applications to the system control structure. Each of the SFR$$K_STATE»PHASE— SCS is performing 
graphics contexts in the list contains one display context traversal processing. 

root node used to link the graphic context to a display SGR$$K_STATE-RANDOWN~SCS has pro- 
context and one virtual root node used as a link to a cessed a "Server Rundown*' request, 
graphics dau structure. (See FIG. 5) Display contexts 3 SOR$$K_STATE-TRAV_UPDATE— SCS is 
may be shared among multiple graphics contexts allow- performing SCS-deferred updates on the client*s graph- 
ing several graphics contexts to operate within a single ics display structure. 

window. Moreover, afl or part of a graphics data stnic- SGR WK_STATE_TRA V_CXT«SETUP— SCS 

ture may be shared among a number of graphics con- ^ performing 3DGC-setup processing. 

texts. 10 SGRS$K.-STATE-TRAV_CXT«. 

^^^T^^M --^vr^^r o^»,T^r»^ CLEANUP— SCS IS performing 3DGC-cleanup pro- 

SYSTEM CONTROL STRUCTURE ccssing. o y y 

The System Control Structure (SCS) serves as the SCR$$K_STATE-.TRAV_3DDC— The 3DDC 
executive program for the structure walker 27 in that it structure is being traversed. 

performs the following functions: 15 SGRWK_STATE_TRAV_CLIENT— The cU- 

Detects and accepts requests for 3DGC travcrsals. *W graphics display structure is being traversed. 

Schedules and dispatches all 3DGC traversals. SOR$$K_STATE«INT-^RROR— SCS has sus- 

Effects updates to SDDCs. pended itself after detecting an internal error. 

Deactivates 3DGCs and 3DDCs as requested by the structure walker 27 requires exclusive write 

traversal control function in the server 101. ^ ^ longword. 

SCS.Frame.3ank 

SCS CREATION AND CONTROL This is a system-wide longword flag indicating which 

As a part of the DDX startup procedure, the win- ^^J^^^^J" displayed, 
dowing server 101 will invoke a traversal control func- „ SGRS$KJANK_A--Framc Buffer Bank "A" is 
tion to allocate and generate the graphics data structure " ^ „ « , 

nodes required for the SCS structure and to initiate its SGMSK^ANK^Fnmt Buffer Bank "B" is 
traversal currenUy bemg displayed. 

Once started, the SCS continues running (i.e.. being '^^ "^^^d ^ "^"^^ exclusive write 

traversed) until all traversal requests have been satis- ^ wiirr^p 

fied. Once all requests have been serviced, the SCS wnll ^ tw rr^ilf ^ i n • ^. • 

suspend itself b7requesting the control processor 13 to i„I?;\lV^f^ r^"""? "^'"m "^^'iJj''.*' 
resSme its traversal at the next vertical retrace event. ^"'^^^^ "^^^^ 

thus preventing excessive SCS request processing. Only SGR$$K_SIDE_A-Window Image Bank "A" is 
under the following exceptional circumstances will ^5 currently active 

SCS traversal be terminated, requiring restart by the SGR$SK_SIDE_B- Window Image Bank "B" is 
^ , ^. • currently active. 

The structure walker 27 requires exclusive write 

(b) An SCS-detected error condition is detected. access to this longword 

(c) The server 101 has terminated SCS traversal by 40 SCS.Perform_TraversaI 

issuing a **Scrver Rundown" request, as part of the xhis longword flag is used internally by the SCS to 
server rundown procedure. detect the absence of traversal requests at the end of 

(d) The structure walker 27 cncountc^ an error condi- ^^^^ processing. The structure walker 27 requires 
tion, at which time it will halt after notifymg the exclusive write access to this longword. 

control processor 13. 43 SCS.Swap_Bank-Requcst 

SCS DATA BLOCK longword flag is used internally by the SCS to 

. , , remember that the frame buffer bank must be swapped 

In order to perform its function, the SCS structure at the end of traversal processing. It is set by 3DDCs of 
maintains a group of control variables in the structure framc-bank double-buffered windows. The structure 
memory 26 known collectively as the "SCS data 50 walker 27 requires exclusive write access to this long, 
block". The contents of this data block are described word. 

below. SCS.Swap-WLUT-JRequest 

SCS.State This longword flag is used internally by the SCS to 

This longword indicates the current state of SCS remember that the window image bank of the WLUT 
execution by taking on one of the following values: 53 must be swapped at the end of traversal processing! It is 

SGR$$K-STATE_INIT1AL— SCS has yet to set by 3DDCs of WLUT^k douWe-buffcred win- 
complete its initial processing. dows. The structure wallcer 27 requires exclusive write 

SOR$$K_STATE_UPDATE— SCS is performing access to this longword. 
SCS update processing. SCS.Scrver_Rundown 

SGR$SK_STATE-IDLE— SCS has suspended it- 6C The windowing server 101 can set this ftag non-xcro 
sicf after finding no traversal requests pending and ex- to cause the structure walker 27 to terminate traversal 
pccts to be resumed by the control processor 13 at the of the SCS gracefully (at the completion of traversal 
next vertical retrace event. phase processing). The structure walker 27 will clear it 

SGR$$K_STATE-.REQ_PHASE— SCS is per- as its final action before suspending SCS traversal, 
forming request processing. 65 SCS.Num—Passcs 

SGRS$1C_STATE_EVENT— SCS has presented This longword contains a count of the passes made 
an event to the control processor 13 and expects to be through the SCS main loop. The structure walker 27 
resumed immediately. requires exclusive write access to this longword. 



06/17/2003, EAST Version: 1.04,0000 



5,251,322 

35 36 

SCS.Num— Frames 3DGC currently being processed by SCS traversal 

This longword contains a count or times SCS tra- processing. The structure walker 21 requires exclusive 
versa! processing has been performed. The structure write access to this longword. 
walker 27 requires exclusive write access to this long- SCS.Current— Client.Pointer 
word. 3 This longword is loaded with the structure memory 

SCS. Previous— Time 26 address of the root of the client 100 graphics data 

At the start of each request/traversal loop of the structure attached to the 3DGC currently being pro- 
SCS, this longword b loaded with a 60 Hz, control cessed by SCS traversal processing. The structure 
processor 13 maintained system time value. It is used to walker 27 requires exclusive write accesss to this long- 
determined the SCS. Elapsed Time. 10 word. 
SCS.Elapsed-Time SCS.Current— OCJD 

This longword is used to hold the interval of 60 Hz This longword is loaded with the graphics context 
system time which elapses between request/traversal identification **QC ID" of the 3DGC being processed 
loops of the SCS. This value is used in blink and re- by SCS traversal processing. The client processes 100 
peated traversal scheduling algorithms. 15 may inspect this longword to determine which of the 

SCS.Watchdog-Timer possibly several 3DGCS has requested its Uaversal 

The SCS wiU load this longword with a maximum SCS.Current«GC_Start«Time 
processing interval at certain points in its execution. SCS.Current_GC_End_Time 
The traversal control function within the server 101 These longwords are loaded with the control proces- 
will periodically decrement this timer and perform 20 sor 13 maintained system time at which traversal of the 
timeout processing if the timer reaches zero. 3DGC commenced and completed, respectively. The 

SCS. Event— Pointer structure walker 27 requires exclusive write access to 

This longword contains the virtual address of a block these longwords. 
of data attached to an event. The structure walker 27 scS. Current_Traversal_Type 
requires exclusive write access to this longword. 25 xhe contents of this longword reflect the type of 

SCS.Qucuc— Node traversal currently being performed. The structure 

This longword contains the handle of a queue node walker 27 requires exclusive write access to this long- 
within the SCS_Update_Processing substructure. word. 

SCS.Pick-Id-Stack 

This longword contains the handle of a system- 30 sgr$sic_draw_traversal 
default Pick ID Stack node. 

SCS.Pick-Path-Stack sgr$$k_hittest_traversal 

This longword contains the handle of a system- 
default Pick Path Stack node. SCS ORGANIZATION 

SCS.Call_Update_Node 35 The organization of the SCS structure is illustrated 

This longword contains the virtual address of the call below, 
node in SCS update processing. This node is required The SCS structure alternates between request and 
by the update mechanism to perform deferred updates traversal processing modes. During the request mode, 
to the SCS. The structure walker 27 requires exclusive each 3DOC on 3DGC list attached to the SCS will be 
write access to this longword. 40 visited in sequence. If requests for traversals are out- 

SCS.Num— GCs standing and the current state of the 3DGC permits, 

This longword reflects the number of 3DGCs in the flags in the 3DGC data block will be updated to cause 
3DGC list attached to the SCS. The structure walker 27 the appropriate traversals in traversal processing. In 
requires exclusive write access to this longword. addition, draw traversals will be performed on all those 

SCS.GC— List—Head 45 3DGCs sensitive to either the frame buffer bank or 

SCS.GC— List— Tail window look-up table image bank if at least one draw 

These longwords describe the doubly-link list of traversal request has been made to 3DGC of that partic- 
3DGCs attached to the SCS. They are pointers which ular class. 

contain the structure memory addresses of 3DGC data Given that at least one valid traversal request was 
blocks, or are both "null", indicating the absence of 50 detected in request processing, the traversal processing 
3DGCs. The structure walker 27 requires exclusive mode will proceed to satisfy all requests accepted. This 
write access to these longwords. is done by visiting each 3DGC on the 3DGC list se- 

SCS.DC— List— Head quentially, and there performing hit-test and draw tra- 

SCS.DC— List— Tail versals (in that order), as required. Any grouping of the 

These longwords describe the doubly-link list of 55 two types of traversals may be performed on a 3DGC 
3DDCs attached to the SCS. They are pointers which each in a given traversal pass, provided that the corre- 
contain the structure memory 26 addresses of 3DDCs. spending requests were issued. If no traversal requests 
The structure walker 27 requires exclusive write access are outstanding, the SCS will be held suspended until 
to these longwords. the next vertical retrace event, at which point request 

SCS.Current—GC— Pointer 60 processing will once again be performed. This is done to 

This longword is loaded with the structure memory avoid an unnecessary load on the structure memory 26. 
26 address of the 3DGC data block currently being 
processed by SCS traversal processing. The structure 

walker 27 requires exclusive write access to this long- 

word 65 BEGIN SCS 

Z^ZL « « - . Define stsie wd mainx suck overflow areas; 

SCS.Current-DC-Pomler jf (gcs State « '-imtiai ') then 

This longword is loaded with the structure memory 3D_Graphic»_lnitiftli2aiion; 
26 address of the 3DDC data block attached to the ENDIF 
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Clear SCS.Pcrfoniu.Tnveru]; 

WHILE (NOT SCS.S«rvcr_Aiuidown) DO 

Scl SCS.Watcbdo».riiner. 

SCS_Up(Ute_ Processing; 

Request— Processing: 

Tr«verML..Proocssmg; 
END DO 

Clear SCS.Server_Jtundown; 
SCS.5ute e> **JUiulown**; 
END 5CS 

BEGIN 3D.OnphiciJiiitializAtioii 

InitiiJixc the SCS-FniBe-Bank to Bank [being 
displayed] 

Initialize the SCS.WLUTUBank to Bank '*A" [active]* 
Clear both valid plines; 
lnirisliT» HierarchicaL-Sttte* 
END 3D— Oraphict— Iniiialiaalion 



10 



15 



When SCS traversal commences, the SCS will imme- 
diately define the state and matrix stack overflow areas, 
initialize some internal flags, and proceed to enter its 20 
main processing loop. 

SCS-Update— Processing 

The first part of SCS loop is SCS Update Processing. 
This section performs deferred updates to the SCS 
through the use of the Update Mechanism 25 



BEGIN SCS^Updale-Processing 
SCS.Sute = "Update— Phase"; 
Perform updates to SCS via call to 
SCS.Can.Update-Node; 
END SCS-Updflte-Processing 



REQUEST PROCESSING 

The request processing portion or mode of the SCS 
loop performs two functions. The first function is to 
effect modifications to the 3DDC data blocks. To do 
this, request processing will examine all 3DDC& known 
to the system and toggle the ''active half* of those 
which have swap requests pending. This processing is 
performed here to assure consistent 3DDC data during 
request and traversal processing. 

Secondly, request processing gathers traversal re- 
quests from 3D clients 100 and the display manager 
(from information contained in 3DDC data blocks). 
This processing is performed by traversing the 3DOC 
structures contained in the 3DGC list. Each 3DGC, 
after detecting the "Request Phase"" SCS State, will 
respond to all ouutanding traversal requests directed 
towards it. Results of this request processing are re* 
tained within the 3DOC. 

In addition, if double-buffered 3DGCs are visited 
(those with 3DDC8 sensitive to either the frame buffer 
bank or window look-up table image bank), a request to 
swap the particular bank will be recorded. This witi be 
used to force draw traversal of all such 3DGCs, and 
cause the actual swapping commands to be delivered at 
the end of traversal processing. 

If no traversal requests are detected after visiting 
each 3DGC, the SCS will put itself to sleep. The con- 
trol processor 13 (ACP) will resume SCS Uaversa) at 
the next vertical retrace event. 



BEGIN Request—Processing 

SCS.Sute — **ReqDest— Phase'*; 
Clear SCS. Swap-^ank— Request: 
Clear SCS. Swap.WLUT— Request; 
DO 

Increment SCS. Nam— Passes; 

SCS Elapsc—Tiroe System VR Count SCS Previous— Timr, 
SCS Previous^Time - System VR Count; 
Traverse— DC— List 
Traverse_GC-Lisl 

IF (NOT SCS.Perfonn_Traversa]) THEN 
SCS.Stale = *ldle"; 

Request ACP 10 resume SCS at next VR event; 
Suspend traversal; 
SCS.Statc - Request— Phase"; 
ENDIF 

UNTIL (SCS.Perfonn_Traversal OR SCS. Server— Rundown) 
END Requst— Processing 
BEGIN Traverse-GC-Usi 

RO = SCSGC-L»t-Head; 
WHILE (RO (GC handle] NOT NULL) DO 
Save physical addr of }DGC dau block in 
SCS .CUrrent_GC_Ptr; 

Generic— 3DGC; 
RO » GCFlink; 
ENDDO 
END Traversal-GC-Lisi 
BEGIN Traverse— DC—List 
RO s SCS.DC-Ust— Head; 
WHILE (RO [DC handle] NOT NULL) DO 
IF (3DDC.System-£nabled) THEN 
IF ODDC.Kill) THEN 
Qear aDDCKill; 
Clear 3DDC. System— Enabled; 
Remove— DC— Links 
Set 3DDCDead; 
ELSE 

IONORE_ATTENTION_INTERRUPTS: 
IF ODDC.Clear-Rcquett) THEN 
Clear 3DDC. Clear— request; 
Send 3DDC.CIear Window generic node 10 clear 
M'tndow; 
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IF (3DDC.Swap_Rcqucsi) THEN 
Toggle 3DDC.Active_H&lf: 
Clear 3DDC.Swap.Request; 

ENDIF 

ALLOW_ATTENnON_IKTERRUPTS: 
IF (3DDC.CLeM_llequ»t) THEN 

C\ar 3DDC.ae»r-Reque»t; 

Send 3DDCClear Window generic node to clear 

window; 
ENDIF; 
ENDIF 

RO - 3DDC.Flink; 
ENDDO 
END Tr»vene_DC_Li»t 
BEGIN Removc—DC-Unlu 
RO - SCS.OC-Ust-Head; 
WHILE (RO [GC handle! NOT NULL) DO 
IF (3DOC.Sy«em_EiuWed) THEN 
IF (3DOCJXLJ>atAj>ir - 3DDC-being^lcted (RU) 

THEN 

3DOC.DC-Oata_Pir -« NULL; 
ENTDIF 
ENDIF 

RO « 3[X3C.FUDk; 
ENDDO 

END Remove— DC_Link* 



TRAVERSAL PROCESSING 

The traversal processing portion or mode of the SCS 
loop visits each 3DGC described in the 3DGC list. This 
action will initiate traversals depending on results of 
request processing and mode information contained 
within each 3DGC. Ccruin hardware-specific opera- 
tions bracket the actual context traversals. In addition, 
one or both bank flags may be toggled as a result of 
window-type detection performed in the previous re- 
quest processing. 



BEGIN Travenal—Processing 

SCS.Sute « "Traversal Phase"); 
IF (SCS.Perfonn-Traversal) THEN 
Clear SCS. Perfomi—Tra versa!; 
Perform Traversal setup actions; 
Travcrse_GC_Liil; 
IF (SCS.Swap— Bank-Jlequest) THEN 
Toggle SCS.Frame_Bank: 
Command RP to swap banks, clear valid plane; 
ENDIF 

IF (SCS Swap-WLUT-RequesO THEN 
Toggle SCS.WLUT_Bank: 
Command RP to swap WLLT image banks; 

ENDIF 

Perform Traversal cleanup actions; 

Increment SCS.Num_Frames: 
END Traversal—Processing 

GRAPHIC CONTEXTS 

A 3D Grai^ics Context (3DGC) control structure 
contains the graphics attributes and control information 
required to request and perform all types of traversals of 
a client 100 graphics data structure. 

Although "3DGC" is referred to as a unique instance 
of the 3IXjC structure, the traversal control maintains 
but a single instance of the actual control structure^ 
known as the "generic" 3DGC. This structure is passed 
a pointer to a "3DGC data block" which provides the 
information corresponding to a particular 3DGC in- 
stance. It is these 3DGC data blocks which arc main- 
tained on the 3DGC list. 

3DGC CREATION AND CONTROL 

A 3DGC is created by the server 101 whenever a 
client 100 calls SGRSCREATE^CONTEXT. Once 
the 3DGC is allocated and generated^ the server 101 
will place it on tail of the 3DGC list. When the server 



101 detects that a client 100 has terminated, all 3DGCs 
owned by that client will be deactivated. The corre- 
sponding 3DOC data blocks will not be unlinked and 
30 reused until request processing has acknowledged the 
deactivation request. 

The client 100 may bind a 3DDC to a 3DGC by 
making the following SGR call: 

35 SGRSSET.DEF.DRAWABLE gc, window_Jd, 

flag. 

A client may bind a client 100 graphics data structure 
to a 3DGC by making the following SGR call: 

^ SGR$SET_DEF_V|RTUAL JIOOT gc. handle. 

3DGC DATA BLOCK 

The generic 3DGC structure is passed a pointer to 
the "3DGC data block" corresponding to the 3DGC 
being traversed. This data block contains control infor- 
mation specific to the 3DGC and is defined below. 

3DGC.Flink 

3DGC.Blink 

These tongwords contain structure memory ad- 
dresses which serve as hnks in the doubly-linked 3DGC 
list. The traversal control function in the server 101 
requires exclusive write access to these longwords. 

3DGC.System Enabled 

This longword flag is set by the SCS when the 3DGC 
is added to the 3DGC list. It ts cleared by the server 101 
when (I) a traversal timeout occurs while this 3DGC 
was being traversed, or (2) a deactivation request is 
detected by the SCS. When this Hag is set, the 3E<jC is 
effectively removed from the system. 
*° 3DGC.Kin 

This longword flag is set by the traversal control 
function in the server 101 when the owning client 100 
dies. It is effectively a deactivation request and is 
cleared by the SCS as an acknowledgement that the 
°' 3DGC is no longer active. 
3DGC.Dead 

This longword flag is set by the SCS when a kill 
request is detected, it is used to identify those 3DGC 
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data blocks on the 3DOC list that may be unlinked and 
reused by the traversal control function in the server 
101. 

3DGC,Systcm_Flags 

This longword contains bit flags used by the SCS. 
The structure walker 27 requires exclusive ^vrite access 
to this longword. 

Do—DC—Draw 

Do-Client— Draw 

Do-Hit-Test 

These flags serve to record traversal requests ac- 
cepted by SCS request processing. 
Bank-2B 
WLUT-2B 

These flags are set/cleared by request processing to 
record the type of double-buffering indicated by the 
attached 3DDC (if any). Traversal processing wUl use 
these flags to determine whether a draw traversal must 
be performed on this 3DOC even in the absence of an 
explicit request. 

3 DGC Num— Request—Passes 

3DGC.Num— Traversal— Passes 

These longwords reflect the number of times this 
particular 3DGC has been traversed and why. The 
structure walker 27 requires exclusive write access to 
these longwords. 

3DGC.Num— Timeouts 

This longword contains a count of the number of 
times a timeout occurred when this 3DGC was being 
traversed. 

3DGC. Num— Update 

This longword contains a count of the number of 
times an update queue node within this 3DGC has been 
traversed. 

3DGC.BIink— On— Timer 

This longword is used to determine when a '^blink- 
cm" traversal is to be performed. 
3DGC.Blink_Ofr_Timer 

This This longword is used to determine when a 
"blink -off* traversal is to be performed. 
3DGC.Repeat-Timer 

This longword is used to determine when a ''re- 
peated*' traversal is to be performed. 
3DGC.TCID 

This longword contains the X Window System re- 
source number of the traversal context associated with 
this 3DGC. 

3DGC.Traversal— Type 

This longword contains a copy of SCS.Current Tra- 
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This longword contains a copy of the 60 Hz system 
time. 
3DGC.GC ID 

This longword contains a 3DGC identifler assigned 
by the server 101, which may be modified by the client 
100 as required. The SCS uses the address of the 3DGC 
data block to distinguish 3DGCs, so this ID need not be 
unique. 

3DGCDC^ata— Pointer 

This longword contains the structure memory ad- 
dress of the 3DDC daCi block attached to this 3DGQ 
or zero if one is not attached. The traversal control 
function in the windowing server 101 requires exclusive 
write access to this longword. 

3DGC.C)ient-Root 

This longword contains the structure memory ad- 
dress of the client display structure attached to this 
3DGC or zero if one is not attached. The cHent process 
100 owning the 3DGC requires exclusive write access 
to this longword. 

3DGCCall-Update-Node 

Thb longword contains the virtual address of a Call 
node which will be traversed prior to any draw tra- 
versal. This node is required by the update mechanism 
to perform deferred updates to the attached client struc- 
ture. The structure walker 27 requires exclusive write 
access to this longword. 

3IX}C.Client-Flag8 

This longword contains traversal mode bits con- 
trolled by the client 100 through the following SGR 
call: 



SORSSET_I5EF. 
modcflags 



.TRAVERSAL—MODE gc, 



40 



45 



versaL- Type which is made available to the client f— Period. 



Automatic— When set and the attached 3DEX: is a 
"double-buffered** window, the SCS e able to re- 
traverse this 3DGC whenever the system display buff- 
ers are swapped. 

Redisplay — When set, the display manager within the 
server 101 is allowed to request draw traversals of this 
3DGC as required to maintain a correct image on the 
display. 

Repeated— When set. draw traversals of this 3DGC 
will be performed at a periodic rate, as determined by 
3DGC. Repeat— Period. 

Blink— When set. draw traversals of this 3DGC will 
be performed at a dual-periodic rate, as determined by 
3DGC. Blink-On-Period and 3DGC.Blink-Of- 



structure to allow traversal type-specific processing 

3DGC.Num_Draw Traversals 

3DGC.Num— Hit— Test-Traversals 

These longwords contain counts of the number of 
traversals. The structure walker 27 requires exclusive 
write access to these longwords. 

3DGC.BliDk State 

This longword contains the current blink state: 



SGRSK-BUNK-ON 



SGRSK_BUNK_OFF. 



3DGC.Blink— On— Period 
SDGC Blink Off-Period 
3DGC.Repeat— Period 

These longwords contain time intervals which deter- 
mine the periodicity of draw traversals when repeated 
or blink traversals mode is in effect. 
Oient— Draw— Request 

This longword flag is set non-zero by the client in 
^ order to request a draw traversal via the following SGR 
call: 



3DGCBlink-Mask 

This longword contains a copy of the SCS.Blin- 
k-.Mask made available to the client structure for aperi- 
odic blink operations. 

3DGCVR-Count 



65 



ir»veisaJ_type-SGR$K_DRAW_TRAVER. 
SAL SGR$REQUEST_TRA VERSAL d»pl*y. 
gc. traversal —type. 

The SCS will clear the flag after the request is de- 
tected. 
Client— Draw— Pending 
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This longword flag is set non-zero by the SCS to 
indicate that a cbent draw request has been seen. The 
SCS will clear the flag after the traversal has com- 
pleted. 

Notify_on_Draw 

This longword flag is set non-zero by the windowing 
server 101 when the client 100 requests notification of 
draw traversal completion. The SCS will clear the flag 
after the traversal is complete, just prior to passing the 
event to the control processor 13. 

Z>raw.-Sequence Number 

The contents of this longword are included in the 
notification event deKvered as a result of a completed 
draw traversal. The traversal control function in the 
server 101 requires exclusive write access to this long- 
word. 

Client Hittest-Request 

Client-Hittest-Pendiog 

Notify_on_Hittest 

Hittest Sequence— Number 

These These longwords arc used for hittest travcrsals 
in a fashion similar to the draw traversal variables men- 
tiOTed above. 

Sync— Request 

Sync— Pending 

Notify-on_Sync 

Sync— Sequence— Number 

These longwords are used by the server 101 in order 
to synchronize with the SCS. 
3DGC ORGANIZATION 

The 3DGC is split into request processmg and tra- 
versal processing, depending upon the content of the 
SCS State variable. 

The request processing requires that the 3DGC be 
enabled by both the system and the client 100 before 
any traversal request processing is performed. If this 
condition is met, requests for service traversal will be 
accepted. Then, if a "visible" 3DDC has been bound to 
the 3DGC. draw traversal requests will be accepted. If ^ 
the client 100 has disabled this 3DGC and requested 
acknowledgement, the client 100 will be notified. 

Traversal processing performs hit-test and draw tra- 
versal (in that order) if corresponding requests are 
outstanding. Acknowledging "notification events" will 
be posted if requested by the client 100. 

Deactivation processing will be performed regardless 
of the SCS State. If the 3DGC is system-enabled and a 
"kill" request is pending, the 3DGC will be togged as 
"dead" and made system-disabled. Although still linked 
to the 3DGC Hst, the 3DGC data block will then be 
available for unlinking and reuse. 
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BEOIN GeiKric_3DGC 

IF UDGCSystcm— Enabled) THEN 
DO CASE (SCS Siate) 
CASE llequest_Fh«sc: 

Clear aDGCSystem-FUgs 
IF (JDGCKill) THEN 
Clear 3DGC.KUI 
Clear 3DGC.5ystein Enabled; 
Set )DGC.Dead: 

Eveni _Notify (opcode = SCS_EVENT/ 
GC-DEATH, 

headers 3DGC num-O, 
reason =GC_DEATH. 
stalus-OK); 

SCS Siatc = "Request Phase"; 
ELSEIF <3DGC.Sync_Requesi) THEN 

Clear 3DGC.S>nc_Reque$i; 

IF (3DGC.Notiry_on Sync) THEN 



Cleu 3DOC.Noufy on_Sync: 

Event— Noafy (opcodesSCS 

EVENT/SYNC 

header »3DCC 

num m 3DOC.Sync_Seq, 

reason-* SYNC, 

MatusaOK; 

SCS.Suic B "Reque<t-.FIuic": 

ENDIF 
ELSE 

tJpdate Jtequest Procetsing; 
Hittesi—Requen _Proccsting; 
Draw Requot—Proccsung: 
ENDIF 

IncreiDciU 3DOC.Nmn Rrqacit-Jaiaca; 
CASE Traversal—Phase: 

Do— Hinest—Prooessing; 
Do— Draw Proocsiing; 
Increment 3DOC.Nuin—travaui— Passes; 
ENDCASE 
EKDIF 
END acncric-3DOC 
BEGIN opdate— Request— Processing 

3DGC.CUent-Update-Pcndisg - 3DOC,Oient.Update 
Request; 

Clear 3DOC.aient— Update— request: 
SCS.5tate « *Trav«fsing Qient Update List" 
Traverse 3DGC.Update— List to peforro deferred updates; 
Increment 3DOCJ<Ittm— Update; 
SCS.Sute t« Hequesl—Pliase** 
Clear 3DGC.aient Update— Peoding; 
IF (3DGCJ>Jotiry_oii-Update) THEN 
dear 3DOC.Notify.on-Update: 
Event— Notify (opcode = SCS-EVENTAJDPATE, 
header «M>GC nttini*3DGC.Update Seq, 
reasons UPDATE. 
sutus=OK>, 
SCS.Sute = "Request— Phase" 
ENDIF 

END Update— request— Processing 
BEGIN Draw— Request— Processing 

IF (3DGC.DC_J>ata-PiT !-NULL) THEN 
IF (3DOC.Visibie) THEN 

Rl B 3DDC(RO).Draw_Request 

R2 - 3DDC(RO).Fonnat 

RO = SCS.Current-GC Pir 

3DGC.atent_Draw— Pending = 

3DGC.aient— Draw 

Request; 

IF (3DGC.aiem.Dnw-PendinB) THEN 

Clear 3DGC.C1ient— Draw— Request; 
Set 3DGC.DO— Client— Draw; 
Set SCS-Perform— Traversal; 

ENDIF 

IF (3DGC.aient-FUgs.Repe»ted) THEN 

CALL Repeat— Mode— Processing; 

ENDIF 

IF (3DGCaient-Flag*.BIink) THEN 

CALL Bhnk— Mode-Processing; 

ENDIF 

IF C3DGCaient-FUgs.R«di5pUy) THEN 
IF (3DGC.Draw-Requcst) THEN 

Set 3DGCDoJ>C-Dr»w; 

Set SCS.Perfonn— Traversal; 
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ENDIF 
ENDIF 



IF (3DOCFonnat indicates Bank 2B) THEN 

Set 3DGCBank_2B: 

IF (3DGC.Do_aient-Draw OR 3DGC 

Do-JXL_Draw) THEN 

Set SCS.Swap— Bank— Request; 

ENDIF 

EL^IF (3DDCFonnatINDlCATES 

WLUT 2B) THEN Sei 

3DCjCWLUT-2B; 

IF C3DGC.Do_Client-I>raw OR 

3DGCDC-DC— Draw) Then 

Set SCS.Swap_WLUT— Request; 

ENDIF 

ENDIF 

ENDIF Visible 

ENDIF Attached to window 
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END Dnw-Jlcquctt—Proceuing 
BEGIN Repeit_Modc-Procctting 
IF ODGCRepcat-Timer < « SCS.EUpsed.Time) THEN 

Set 3DGCSysiem F]ag».Do.aiest_Dniw. 

Do— Repeated 

Sci SCS.Pcrfonii-THvenal; 
3DGC. Repeat—Timer » 
JDGCRepeat— Period; 

ELSE 

DecremcDt 3DGCRepeat_Tiiner by 
SCS.Elapicd— Time; 

ENDIF 

END Repeat Mode— Procesing 
BEGIN Blink-Mode Procentne 

IF (3DOC.BUjik-St«te - *W)THEN 
IF tJDGCBBnk OfT-Timer <« 
SCS.EUpsed-TiiBe} THEN 

Set 3DOC.Syuem_Fhgs.Do-aiei>t- 

Dnw.Do— BKnk 

Set SCS. Perform— TravereaJ; 

3DGC.Blink_Stiie - "On"; 

3DGC.Bliiik OfT-Timer « 3DGC.BUnk- 

Off Period; 

ELSE 

Decrement 3DGC.BIifik— Off— Timer by 
SCS.£Upsed Time: 

ELSE 



IF (3DGCBIink-On_Ttmer <- SCS.Elapsed-Tirae) 
THEN 

Set 3DGC.Sy«cm_FUgs.Do_Client_ 
Dniw,Do^B]ink 
Set SCS.Perform-TraversaI: 
3DOCBlink-St«e = "OfT*; 
3DGC.Blink-On_rimer « 3DOCBlink_ 
On_Penod; 

ELSE 

Decrement 3DGC.Blink_On— Timer by 

SCS.Elapsed Time; 
ENDIF 
ENDIF 

END BIink_Mode_Proccsstng 
BEGIN Do_Dr»w_Processing 

IF (3DGC.Do-aiert-Draw) THEN 
Clear 3DCCJDo.Oient_Draw: 
5C5.Curreni Traversal— Type - "Draw**; 
Draw— Traversal; 

Clear 3DGC.CIieot_Dnw— Pending: 
IF ODGCNofity-on-Draw) THEN 
Clear 3DOC-Nofiiy_on_Draw; 
Send "Begin_3D_Context" to RP to allow 
BM processing; 

Send Event—Notify (opcodeaSCS— 
EVENT/DRAW, hc*der.3DGC, 

num » 3DGC.Draw_Seq, 

rcason^DRAW, 

siatu»=OK): 
SCS. State = 'Traversal— Phase" 
ENDIF 

ELSE IF (3DOC.Do_DC_DrBw) THEN 

aear 3DGC.Do_DC-Draw: 

SCS.Current— Traversal—Type -» "Draw"; 

Draw— Traversal; 

Gear 3DDC Draw— request; 
ELSE IF (SCS.Swap-Bank-R«queft) AND 
{3DGC.Bank.2B 

OR <SCS.Swap-WLUT_Request) AND 
(3DGC.WLUT-2B) 

IF (3DCC.aient-FUgs.Aalomatic) THEN 

SCS.Current— Travcnal—Type = **DrBw*'; 

Draw- Traversal; 

ENDIF 

ENDIF 
END Do-Draw Processing 
BEGIN Draw- Traversal 

SCS.Suie = "Traversing Update Li$l" 
Process client updates via 3DGCCall 
Updaie-Node; 

Increment 3DGC.Num_Updaie; 
SCS.State - "Traversing Context Setup" 
Perform 3D Context setup actions; 
SCS.Current_DC_Pir = 3DGC. DC- 
Data— Pi r; 



SCS.Suie m 'Traversing 3DDC' 
Traverse (generic) 3DDC to let-ap rendering 
(window) environment; 
3 (Restore RO - <SM) add reu of current 

3DOC): 

SCS.Current— Client Pir « 3DOC.aicnt— 
Root; 

SC:S.Current— OC— ID - 3DOC.Gc— ID; 
3DGC.Cttrrcnt— Traversal Type - "Drw" 
10 3DOC.Bliak Mask m System Blink Mask 

(aU ACP); 

3DOC.Vr-Cottnt - System VR Count 
(ala ACP); 

SCS.CiiTTent-OC..Start— Time « System 
VR Count (aU ACPh 
13 SCS.Siat« - Traversing Client" 

Traverse Ctical Structure to draw cBeni's 
inuge; 

SCS.Currem-GC-Ei>d-Ttine « System 
VR Count (aU ACP); 
Restore RO » (5M) address oT current 
20 ^^^J 

SCS.Sute - Traversing Context Setup" 
Perform 3D Context cleanup actions; 
Increment 3DGC. Draw— Count; 
SCS.State - Traversal Phase" 
END Draw-Traversal 
BEGIN Hittest-Request-Processing 

3DOCClient_Hittest Pending «- 
3DOCaient Hittcsi Request; 
IF (aiXJCCKent-Hittesl-Pending) THEN 
aear 3DGOCtieni-Hittcsi— Request; 
Set 3DGC.Do-Hittest; 
Set SCS-Perfonn— Traversal; 
ENDIF 

END Hittest— Request— Processing 
BEGIN Do-Hlttest— Processing 

IF (3DGC.Do-Hittest) THEN 
Clear 3DGC.Do— Hittest; 
SCS.Current— Traversal—Type «■ "Hittest"; 
Hittest— Traversal; 

Clear 3DGC.Cliei)t Hittest— Pending; 
IF (3DGC.Notify_on_Hittest) 
THEN 

aear 3DGC.Notify-on— 
Hittest; 

Send "Begin- 3D 
Context" to RP to allow 
BM processing: 
Event— Notify (opcodes 
SCS-EVENT/HITTEST, 
header »3DGC. 
num B 3DGC. 
Hittest— Seq, 
reason »• 
HITTEST. 
status B OK); 
SCS Sute - 
Traversal- 
Phase" 
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ENDIF 



ENDIF 
END Do— Hittest— Procetting 
BEGIN Hittest-TraversaJ 

SCS.Sute = Traversing Cutest Setup" 
Perform 3D Context setup actions; 
SCS.Current-CUent-Ptr = 3DOC.aient_ 
Root; 

SCS.Oifrent_GC— ID ^ 3DGC.GC-ID; 
3DGC.Current Traversal-Type - 
"Hittest" 

dO 3DGC. Blink—Mask « System Blink Mask 

(ala ACP); 

3DGCVR-Count - System VR Count (ala 
ACP); 

SCS Current— GC— Surt-Time - System 
VR Count (ala ACP); 
65 SCS.State = Traversing aient*- 

Traverse Qient Structure to hittest client's 
image; 

SCS-Currem-GC—End-Time = System 
VR Count (ala ACP>, 
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. list. The structure walker 27 requires exclusive write 

access to these longwords. 



Restore RO - (SM) addreu of current 3DDCSyStcm_Enabled 

sSfute - -Tr.vmi«g Context Setup- . "^'t^^ ^^f ^^,^^"1 ^^P^ 

Pcrfonn 3D Context cleanup ictkms; 5 IS added to the 3DDC list. It 15 cheared by the SCS as a 

Increment SDOCitittest Count; result of a deactivation request. 

SC&Sute = "Treversal Phue" 3DDC.ICill 

END Hitt«t-Tr»vert»i yjjj, |ongword flag is sct by the traversal control 

Tunction in the server 101 when the owning client 100 

rfcicDi Av rY^MXcYT«s " cfFectivcly a deactivation request and is 

^ DISPLAY CON 1 fcA I & ^j^^ request processing as an acknowl- 

A 3D Display Context (3DDC) control structure edgenoent that the 3DDC is no longer active, 

detervnines the mapping of client-generated images onto 3DDC. Dead 

a rectangular area of the screen. When called from the This longword flag is set by the SCS when a kill 

3DGC, the 3DDC loads subsystem state related to the is request is delected. It is used to identify those 3DDC 

associated display manager window (the rendering en- data blocks on the 3DDC list that may be unlinked and 

vironment). The 3DDC is passed an indication of which reused by the traversal control function in the server 

bank is currently being display. This is used to set up 101. 

bank*sensitive attributes, such as write masks, etc. 3DDC.Swap— Request 

The rendering environment includes: 20 This longword is used to synchronize structure 

Window Number walker X7 and server 101 access to the 3DDC data 

Window Mask block. When the traversal control function in the sefver 

Foreground Color 101 finds this flag clear, it is immediately allowed access 

Background Color to the ''inactive"* half of 3DDC dau block. At this point 

Base Matrix 2$ it can update the inactive half and set this longword 

Base Viewport non-zero. When the SCS finds this flag set, it will swap 

Pixel Format active and inactive halves and clear this flag. 

Default Line Filter If the traversal control function in the server 101 

Pixel Processor setting Ands this flag set (indicating the SCS has yet to see a 

Filter Rounding Enable/Disable 30 previous swap request), it has two options; 

Use Valid Plane on FB Read (a) I^ can wait until the SCS clears this flag. This will 

Frame BufTer Write Mask assure that the previously updated half b seen at least 

Pipeline Enable Mask once- . « . ^ . . ^ 

Although a ^'SDDC*' is referred to as a unique in- Cb) It can clear the flag itself, wait a short penod of 

stance of the 3DDC structure, the traversal control 35 time, and then update the "inactive'* half at that point, 

maintains but a single instance of the actual control Note, however, that the previous swap request wUl 

structure, known as the "generic" 3DDC. This struc- most likely be ignored. The wait is required in case the 

ture is passed a pointer to a "3DDC data block" which SCS is currently processing the previous request. (At- 

provides the information corresponding to a particular tention interrupts will be disabled by the SCS during 

3DDC instance. ^ period (for 3 nodes), so this critical region is well 

3DDC CREATION AND CONTROL ***^?J!^^*a 

A client process 100 creates a window by making the i]^Pp-^^*^^T*\ . , . . . . . ^, , „ . 

appropriate call to the windowing system 101.102,103. ^ ThK longword mdicates which of the halves of this 

As a result of this action, the Display Manager passes a currently bemg ustd by S^ re- 
description of the window (in a "3DDC descriptor") to « q««t and traversal processmg. If zero, the first half is 

the traversal control function in the server 101. This active, othcnwse the second half is active, 

routine will allocate a 3DDC data block and format it ^The 3DDC date block contaii^ consecutive copies 

with information extracted from the 3DDC descriptor. (halveO of the ^^^^ group of items. 

If the client 100 desires to attach this window to a ^ , « - *u • ^ 
3DGC (or later detach it), it will make the following » When this longword flag is non-zero, the window 

SGR ca^l. This routine, depending on the flag parame- represented « (at least partiaUy) v^^ u^rccnAT 

ter. will either enter or^ove the address of the Jhe wmdow is either totally obscured or iconfied, 

3DDC data block in the corresponding 3DGC data ^ ^oDC^StS^ attempted. 

55 This longword flag is sct non-zero at the behest of 

SGR$SET_DEF_DRAW ABLE gc, window_id, data manager in order to request draw traversals for all 

flag 3DGCs bound to this 3DDC. This action may be re- 

_ , • VI »^;r^r th. -irkTv^ ria^a quired, for example, when a window incurs an exposure 

The display manger is ^^^^"^"^^^^ 2vent or resize 5>eration. The SCS will clear tteflag 

block m response to <^»^8es/o the v^^^^ ^^^^^^ ^^^^^^ » 

A draw traversal request will be issued for all 3IXjCs innr 

attached to this 3DDC if the 3DDC retains visibiUty 3DDC.Window_Number 

after This longword contains the window number, in a 

3DDC DATA BLOCK ^^^^ suitable for entry into a Generic node. 

3DDC.Window_Mask 

3DDC.Blink . . ^ »j This longword cotains the window mask, in a format 

These longwords contain structure memory 26 ad- ^^^^^^^ .^^^ ^ ^^^^^ 

dresses which serve as links in the doubly-bnked 3DDC 3DDC.Pixcl_Formal 
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This longword contains the pixel format of this win- 
dow. 

IB. 4 bit Mapped 

IB. 4 bit Gray Scale 

IB, S bit Mapped 

IB. 8 bit Gray Scale 

IB. 12 bit RGB 

IB. 24 bit ROB 

WLUT 2B, 4 bit Mapped 

WLUT 2B, 4 bit Gray Scale 

WLUT 2B. 8 bit Mapped 

WLUT 2B. 8 bit Gray Scale 

WLUT 2B, 12 bit RGB 

Bank 2B, 4 bit Mapped 

Bank 2B, 4 bit Gray Scale 

Bank 2B. 8 bit Mapped 

Bank 2B. 8 bit Gray Scale 

Bank 2B. 12 bit RGB 

Bank 2B, 24 bit ROB 

3DDC.Background— Color 

This longword contains the window background 
color in a format suitable forentry into a Set Back- 
ground node. 

3DDC.Foreground— Color 

This longword contains the virtual address of the ^5 
Base Matrix X3 node which is traversed to load the base 
matrix. 

3DDC.Base-Matrix_SGR 

This longword contains the vinual address of the 
Base Matrix X3 node which is traversed to load the base ^ 
matrix. 

3DDC.Basc-Matrix-GDS 

This longword contains the physical address of the 
Base Matrix graphics display structure node which is 
traversed to load the base matrix. 

3DDC.Base— Viewport_SGR 

This longword contains the vinual address of the 
Base Viewport X3 node which is traversed to load the 
base viewport 

3DDC.Basc-Viewport_GDS ^ 

This longword contains the physical address of the 
Base Viewport graphics data structure node which is 
traversed to load the base viewport. 

3DDC ORGANIZATION 

45 



BEGIN Geiieric_3DDC; 

Use 3DDCActjve_Hiir to setup indirect addressing; 

Load Base MfttrU; 

Lo»d Base Normal Matrin; 

Load Bast Viewpon; 

Load Window Number; 

Load Window Mask; 

Load Foreground (Line) Color: 

Load Background Color; 

FonDal_Dependem_Setup; 

Ckar 3DDC.[>iaw.Jlequesl; 
END Genenc.3DDC: 
BEGIN Formal Dependent Setup 

IF (DI>C.Format.Bufrering = -WLUTJanJu-Doiible 

Buffered**) 

IF (SCS.WLUT-Bank ^'A") THEN Plane Mask « 
3DDC. 

Plane Mask_fi: 

ELSE 

Plane Mask » 3DDC.PIane-Mask_J^: 
ENDIF 

Clear Onput-side) window io the background color 

ELSE 

Plane Mask ^ 3DDC.Planc_Mask_A: 
ENDIF 

IF (3DEX:.Forraat. Buffering « "Framc_Bank_ 
Double—BufFcTcd**) 



50 

<ontinued 



"A") THEN (A being displayed) 
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THEN 

IF (SCS Frame Bank . 
Source Bank ■ "B"; 
Destination Bank » '*B only; 
Enable valid plane when reading pixels; 
ELSE 

Source Bank = "A**; 
Dettinalion Bank ^ **A only"; 
Enable valid plane when reading pixels; 
ENDIF 

ELSE <**Sin8le Buffcred", **WLUT_Bank_Doubte- 
BufTered") 

Source Bank » "A**; 
Destination Bank » **A and B**; 
Disable valid plane when reading pixels; 
ENDIF 

IF (3DIX:.FonDat.aass - "Mapped**) THEN 

Load Pixel Proc ALU mode » "Store"; 

Disable rounding in PPA; 

Disable additive blending oo line crossings; 

ELSE C*RGB". '•Grayscale") 

Load Pixel Proc ALU mode - **Add with Ceiling"; 

Enable rounding in PPA; 

ENDIF 

Case SDDC.Formst.Depth 
'*4 bits": 

Enable 4-bit ALU mode; 
••8 bttt": 

Disable 4-bii ALU mode; 
**12 bits": 

Enable 4.bit ALU mode; 
"24 bits": 

Disable 4-bit ALU mode; 
ENDCASE 
END Format— Dependent_Setup 



The following is a summary of the various routines at 
the disposal of the clients 100 and server 101 to enable 
them to interface with the traversal control structures. 

SGRSCREATR-CONTEXT display, gc 

display 

This is the X Window System display variable which 
specifies a particular connection to a server 101. 
gc 

This is the identifier of the 3DGC created. 

A client process 100 will call this routine to create a 
graphics context <3DGC). 

SGR$SET«DEF-DRAWABLE gc, window_id, 
flag 

gc 

This is the "SDOC ID" of the 3DGC to be attached, 
windowed 

This longword contains an identification of the win- 
dow which is to be attached to, or deuched from, the 
3DGC. 

flag 

If this longword is set non-zero, the window will be 
attached If it is zero, the window will be detached. 

A client process 100 will call this routine to attach or 
detach a window (3DDC) to or from a graphics context 
(3DGQ. 

SGR$SET_DEF_VIRTUAL-ROOT gc, handle 
gc 

This is the "3DGC ID" of the 3DGC to be attached, 
handle 

This longword contains the vinual address of the 
node which is to be entered as the root node of the 
3DGCs client structure. 

A chcnt process 100 will call this routine to attach a 
graphic data structure (client structure) to a graphics 
context (31XX:). 
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SGR$SET-.DEF_TRAVERSAL_MODE gc, can subsequently be used to link this window to any 

modeflags number of 3DOC$. 

gc SOR$UPDATE_3DDC 3ddc_descriptor. 3ddc_db 

This is the "3DGC ID" of the 3DGC lo receive new 3ddc-.dcscriptor 

traversal modes. 3 A structure of longwords. passed by reference, which 

modeflags contains an updated description of the window. 

This longword specifics the traversal modes as dc- 3ddc_cb 

scribed with respect to the 3DGC. CIient.JTages on p. The virtual address of the 3DDC daU block to be 

59, updated, passed by reference. 

A client process 100 will call this routine to set-up the 10 The server 101 will call this routine to update the 

appropriate travereals modes of a 3DGC. These modes ^DDC structure associated with a newly redifined/- 

affect subsequent traversals of the 3DGC. modified window. This routine may request a draw 

SGRSREQUEST-TRAVERSAL gc. traver- traversal of all 3DGCs attached to this window, given 

^ that the window is visible and the 3DOCs are properly 

" 15 enabled. 

ks is the 3DGC to be traversed. fS'^^^^^.^n . u . . ^„ 

traversal— type server 101 will call this routine to gracefully 

This specifies the type of traversal desired: terminate traversal of the SCS. 

SGR$K_DRAW_TRAVERSAL-for a draw tra- ,„ , P'?" J^Ti ff*"/"*"!^' T*"' 
y.^f^ 20 functions it should be nnderstood that the three dimen- 

SORSK_HlTTEST_TRAVERSAL-for a hit-lcst «ional graphics contexts (3DGC's) tie all of the 

t rsal control functions together. The structure walker 37 

. ' ,nn „,iii .vi. ,^„,i«. traversal of each 3DCC through the request processing 

A chent process 100 will call this routine to reque« .^ul traversal processing moda of the SCS provides the 

thatapanicular type of traversal be performed on the „ wal^T^l^tHT ^p^cs .tfnT,ut« ^ 

cTxii-i -TO A vEoc A I cta-tt: »^ tr««*r control snformation necessary to perform all traversals 

SGRSINQ-TRAVERSAL-STATE gc. traver- ^ ^^^^^.^ structure. As UJustrated in FIG. 5. 

sal-type, waitnag. sute ^.^^ provided with cafls and routines to 

5^. . i_ -T^^^ . attach a graphics dau structure (GDS) to a 3DGC 

This IS the 3IXjC m question. through a 3D virtual root and to control traversal re- 

traycrsal-typc quest flags in the attached 3DGC The client 100 may 

This longword ts used to specify the type of traversal ^ ^-^^^ ^ ^j^q^ ^^j^q ^^^^ 

in question. . , ^ by the display manager to merge a three dimensional 

SGR$K_DRAW_TRAVERSAL-for draw tra- functionality into the X Window system. In this man- 
versa] co mpleti on ^ . , ^. 35 ner, the asynchronous traversal of the structure mem- 

SGR$K_HITTEST_TRAVERSAL-for a hit-test 26 is controlled by means of the traversal request 

traversal completion mechanism available to the muhiple clients lOQ and 

waitflag through the request and traversal processing modes to 

If this longword flag is non-zero, this routine will not systematically create a node traversal sequence for or- 
retum until the specified event has occurred. Otherwise 40 dered flow of graphics daU and commands to the 
the status of the event is returned immediately. ^ graphics pipeline processor 29 through the line 30. The 
A client process 100 will call this routine in order to ordered flow of graphics data and commands assures 
obtain status or notification of a particular traversal maximum efficiency in the utilization of the resources of 
completion. the graphics subsystem 17 to efficiently process a muJti- 

SGRSSTARTUP 45 pie of application programs by organizing traversal 

The server 101 will call this routine to initiaUzc the requests and related graphics data structures and win- 
traversal control function operating in the server pro- dow information through the 3DGCs and connected 
cess 101. This action includes the creation of all control 3DDCs for the continuing asynchronous, traversal op- 
structures and the commencement of SCS traversal. cration of the structure walker 27. 

SGR$CREATE-3DGC gc 3dgc_db 50 .^t,^ 

RENDERING PROCESSOR CONTROL AND 

This is the identifier of the 3DGC to be created. BITMAPS GRAPHICS INTERFACE 

3dgc_db The graphics subsystem 17 of the invention provides 

The virtual address of the 3DGC data block associ- two types of graphics environments to the user: 3-D 

ated with the new 3DGC is returned in this longword. 33 graphics, as described above, and bitmap <2-D) graph- 

The server 101 will call this routine to create a new ics. The bitmap environment is similar to its 3-D envi- 

3DGC structure in response to a client 100 invoking ronment, though somewhat simpler. As with 3-D, a 

SGRSCREATE-CONTEXT. bitmap application communicates with the graphics 

SGR$CREATE_3DDC_descriptor, 3ddc_jdb subsystem 17 through the use of data structures stored 

3ddc— descriptor 60 in shared memory (structure memory 26). These data 

Astructureoflongwords, passed by reference, which structures, the bitmap graphical data structures, are 

contains an initial description of the window. traversed and processed by the rendering processor 36, 

3ddc_db The rendering processor 36 performs multiple tasks 

The virtual address of the 3DDC data block created, in the system: 3-D rendition, bitmap rendition, bitmap 

returned by reference. 65 graphical data structure traversal, and video subsystem 

The server 101 will call this routine to create the control. The term "rendition" in computer graphics 

3DDC structure to be associated with a newly-defined refers to techniques used such as coloring, shading and 

window. The address of the 3DDC data block returned lighting to realistically draw an object. The rendering 
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processor 36 also regulates the scheduling of Bitmap loaded all the commands in the initialization list arc 
and 3-D graphical operations. In addition to traversal executed, though not consumed. The initialization list is 
and rendition^ the rendering processor 36 also provides modified eiihcr by direct memory access from the host 
an interface for video subsystem (Color Lookup Table, and control processors, or through commands executed 
Window Lookup Table, and Cursor Management). 5 by the rendering processor 36. Thus, the client detcr- 

The rendering processor 36 is a shared resource in the mines the kind and amount of state required for a bitmap 
context of bitmap graphics. The graphics provides two graphics context through the use of its initialization list, 
levels of interface. The first interface provides primitive A bitmap graphics context piesenu a processing envi- 
access to hardware/microcode facilities with little ronment similar to that of general purpose load/store 
added abstraction. The second interface is a model level 10 architecture. In this environment each graphics context 
interface that provides the functionality and senumtics has a current set of general purpose registers— 32 regis- 
expected by the standard Digital windowing systems (X ters in all. The content of the general purpose registers 
or UIS). The interface between the rendering processor are guaranteed to be consistent throughout the lifetime 
36 and the rest of the graphics system was designed to of the graphics context. In comparison, the hardware 
optimize the sharing of the rendering processor 36 15 context is not guaranteed to remain consistent between 
among bitmap graphics and 3>D graphics applications. one execution of a graphics context and another and as 
GRAPHICS CONTEXT * result the hardware context must be made consistent 

when a graphics context is loaded. 

The rendering processor 36 and drawing hardware Normally, a register is used by the rendering proces- 
maintains state that is used or modified when graphics 20 sor 36 as explicitly instructed by a command. The ren- 
commands are executed. The total of all such state com- dering processor 36 does, however, require access to 
prises a context in which drawing commands are exe- some dau while it loads and executes a graphics con- 
cuted. This context, the hardware context, is managed text This data is implicitly accessed during the execu- 
solely through the use of commands executed by the tion of a graphics context and is statically assigned to 
rendering processor 36. 23 certain registers. The initialization list pointer is an ex- 

A multitasking graphics environment b obtained by ample of dau that the rendering processor 36 uses while 
sharing the one hardware context among multiple loading a graphics context and the rendering processor 
graphics context. A graphics context represents a 36 can assume that it will find this pointer in register 2, 
thread of execution and the state needed for the execu- though register 2 is a general purpose register in all 
tion of commands in that thread. Multitasking is done 30 other respects, 
much the same way that multiple process contexts share 

a hardware context in a timesharing systerii: scheduling TRAVERSAL 
and execution. Graphics contexts are traversed by the Graphics contexts are stored in dau structures that 
rendering processor and those marked arc scheduled for arc traversed by the structure walker for 3-D and the 
execution. 35 rendering processor 36 for bitmap. This implies that the 

In addition to multitasking, each graphics context rendering processor 36 plays two roles: raster engine 
provides sute and a mechanism to dynamically load and bitmap graphical daU structure traverser. All bit- 
that sute into the graphics hardware at any time during map graphics context daU structures are linked to a 
the execution of graphics commands. In this way, the bitmap daU structure root (bitmap root) and all 3-D 
thread of execution is decoupled from the sute needed 40 graphics context dau structures are linked to a 3-D daU 
for execution, structure root (3-D root). Pointers to both the bitmap 

Execution of a graphics context occurs in two phases: and 3-D roots reside in reserved structure memory 26. 
loading phase and update phase. During the loading Traversal is the term used for the way a class of 
phase the hardware context is brought to a sute consis- graphics contexts are selected for execution. A list of 
tent with the graphics context being loaded. The load- 45 graphics contexts is traversed by stepping through the 
ing phase for a bitmap graphics context typically sets up list and visiting each context in a serial fashion. During 
drawing state in the hardware context, but rarely per- each visit, it is determined whether or not a graphics 
forms drawing. The loading phase for a 3-D graphics context requires execution and if so the context is 
context typically sets up state in the hardware context, loaded and executed. 

bu( also draws an image containing a view of a world. 50 There may be up to three traversals in progress at any 
During the update phase, commands are consumed given lime: low priority 3-D traversal, low priority 
that change the description of a world. The description bitmap traversal, and high priority bitmap traversal, 
of a bitmap world is contained in a bitmap dau structure though only one of the three may be executing at any 
so that an update to the description requires editing a given time. A traversal is either inactive, active, or 
bitmap (rasterization). 55 suspended. A traversal is initially inactive and is acti- 

The description of a 3-D world is contained in a more vated through use of a signal mechanism. When acti- 
complex dau structure. This dau structure is usually vated, the first graphics context in the list is visited. A 
traversed during the loading phase so that an update to traversal may be suspended when another traversal 
the description requires editing part of that daU struc- needs to be activated or resumed. When a suspended 
ture. In both the 3-D and bitmap case a daU structure is 60 traversal is resumed the current graphics context in that 
edited with the only difference being in the daU types traversal is visited. A traversal becomes inactive after 
and operations used. all graphics contexts have been visited and no signals to 

The rendering processor 36 loads a bitmap graphics that traversal are pending, 
context by executing a list of commands that update the When a graphics context is visited, two bits, local to 
hardware context; this list is referred to as the initializa- 65 the graphics context, are used to determine if the graph- 
tion list. The initialization Ibt is used to obtain consis- ics context requires execution. The first bit indicates 
tency of the hardware context before any drawing com- that the graphics context requires execution at low 
mands are executed. Each time a graphics context is priority. The second bit indicates that the graphics con- 
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text requires execution at high priority. The traverser 
checks and clears (interlocked) the appropriate bit(s) as 
the first step of a visit. These bits are located in the two 
low order bits of register 1 in a graphics context Refer 
to FIO. 8 which illustrates graphics context and tra* 5 
versa! model. 

A bitmap traversal is signaled to activate through the 
use of two bits Qow priority run bit and high priority 
nm bit) in the bitmap root and through the use of the 
rendering processor 36 control status register (CSR). It tO 
i$ through the CSR that the host controls the rendering 
processor 36. To activate a low priority bitmap tra- 
versal the low priority run bit is set. This bit is checked 
and cleared (interlocked) by the rendering processor 36 
on a time basis or in response to CSR attention. Signal- 15 
ing for a high priority traversal is done much the same 
way, through using the high priority run bit in the bit- 
nap root. 

A transaction is a series of commands that comprise 
an operation or program. Commands in a transaction 20 
execute synchronously with respect to one another, but 
may execute asynchronously with conunands in other 
transactions. Multiple transactions execute synchro- 
nously within a graphics context, or asynchronously in 
multiple graphics contexts. A transaction may be lermi- 25 
nated explicitly by using the end-transaction command. 
A bitmap transaction is terminated implicitly when the 
command queue is exhausted. 

A transaction may lock the rendering processor 36 
for some period of time, normally to maintain some sort 30 
of data consistency. This is accomplished through use 
of lock and unlocked commands. While the rendering 
processor 36 is locked the current traversal may not be 
suspended and the current graphics context continues to 
execute until an unlock command is encountered. 3S 

The rendering processor 36 alternates between exe- 
cuting conmiands from bitmap graphics contexts and 
executing commands from 3-D graphics contexts. 5-D 
commands are taken from the geometry pipeline. In 
general, low priority 3-D and low priority Bitmap 40 
graphics contexts are equal in priority. The following 
rules are used to establish a scheduling policy that in- 
sures fairness between 3-D and bitmap graphics execu- 
tion. 

A bitmap traversal becomes pending whenever either 45 
of the run bits in the bitmap root is set. 

A pending high priority bitmap traversal is initiated 
as soon as possible: any time during a 3-D transaction or 
between any two low priority bitmap transactions. 

A high priority bitmap traversal traverses all the 50 
bitmap graphics contexts from first to last without inter- 
ruption. 

A pending low priority bitmap traversal is initiated 
after a 3-D cnd-of-framc command is received or imme- 
diate! y after the current 3-D transaction terminates 55 
following a VSYNC. 

A low priority bitmap traversal traverses all the bit- 
map graphics contexts from first to last, but may be 
suspended and resumed multiple times. Traversal is 
suspended and returned to the pending state following 60 
VSYNC. During this suspension, execution of pending 
3-D transactions is initiated. 

A bitmap graphics context becomes pending when 
either its low or high run bits is set. 

A pending high priority bitmap graphics context is 65 
executed whenever it is traversed. 

A pending low priority bitmap graphics context is 
executed only when traversed at low priority. 
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If the number of commands executed in a single visit 
to a graphics context exceeds a limit specified in the 
bitmap root, the graphics context is suspended and 
made pending (rescheduled). Traversal then proceeds 
to the next graphics context. 

Execution of a bitmap graphics context is terminated 
when the command queue is exhausted. 

If the rendering processor 36 is locked by a graphics 
context all scheduling is deferred until an unlock com- 
mand is encountered. If the command queue is ex- 
hausted, tlie rendering processor 36 continues to retry 
the command queue until an unlock command is en- 
countered. On every retry, the rendering processor 36 
waits 5 us to avoid bus deadlock. 

The following is an example of a schedtiling algo- 
rithm used by the rendering processor 36. This algo- 
rithm implements the scheduling policy set out above. 



rp-kUe_k)opO 
BEGIN 



[F (rp— mention) 
BEGIN 

IF (TeMADdaear(icsnicm.t»mroot. 
stttus.hi)) 

rtn hi bm—travemlQ 

END 

IF ((rpt— Jinention) OR (vsync— occured)) AND 
(NOT 3d_tnnsBCtion) 
BEGIN 

IF (TetiAndC]ear(rcsiDcm.bcnFOOl. 

tutus.hi)) 
do_Ju_bai travenalO 

IF <TestAndClear(resiDein.bfnroot. 

sU1us.lo)> 
do—Jow— bnu.traverulO 
END 



END 

do_hi.bin— travcnatO 
BEGIN 

FORALL gc IN resmem.bcnrootgdttt 
IF (TcsiAndCleu<gc.cutus.hi)) 
BEGIN 

lo*d_base_regisler(gc) 
FORALL cmd IN gciniq 
eucutc— coinoiu»d(gc,cnu)) 
FORALL cmd In gceuq 
consume— conunandCgc^cnid) 

END 

END 

do_low_bm_traventlO 
BEGIN 

BUrting_gc — resmetn.bmroot,gctist.cuTTent; 
FOREVER 

BEGIN 

gc rcsnieni.bmroo(.gDlistxitrrent; 
IF (rc3inciD.bniTO0t.gclistxufreiitj>cxt 
EQL nil). 

reuikem.bmroot.gclist.current b 
ffesokein. bmroot gclitt.nnt; 

ELSE 

resraem.bmrootgclisi.curRst s 
mmeiD.bmrootgcUsi.curreDLDext; 
IF (re8tAiKtC3ev<g&fttKusJo)) 

BEGIN 

kmd.base_ccgister(gc) 
FORALL cmd In gc.iniq 
e»ecttte_comin»nd(gc,cmd) 
FORALL cmd IN gc.ejieq 
BEGIN 

IF (TesiA&dClear(mtncxn.bmroot. 
ttatus.hi)) 

do_hi_bm_traveruIO 
consume— cominand(gc,cmd) 
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■contiimed -continued 

IF ((viynch-occured) OR . Bit Dtscription 

(reschedule—requested) OR 

(coramind-conni > rcsmem. reserved - and zeroed 

bmrooLcoinm«nd_lLmlt)) 5 

AND (NOT rp_Jocked) break; ^^^^ ^ commands that make up the 

END initialization list. 

IF ((Not retmem.bmroot.tutus) AND (luning^gc EQL Current — A pointer to the previously executed bit- 

rcfmem.bnroot^clttt.cimt)) OR map graphics command. When low priority bitmap 

^(v.y«ch_occttred) break: 10 traversal is inactive it points to First. 

EHju First — A pointer to the first bitmap graphics com- 

mand. 

Rescheduling defers the execution of commands in a to the last bitmap graphics com- 

graphics com«t until the next traversal. A reschedule » Base register is a pointer to 32 general purpose registers, 

requires that botfi the graphics cont«t rui> bit and the Bitmap data format pertains to how WmTap datTL 

proceeds on to the next graphics context bitmap may be organized in memory. The rendering 

^•'"v T^P'^^irf "^^^ "^7""" * ^ P'«^^ ^ micniode manages fouTformats: 

count m the bitmap root The traversal count ts mere- W Cell Array 

mented whenever a low priority bitmap traversal is Planar 

completed. Oients can use this count to determine Unpacked Byte 

whether a low priority bitmap traversal has taken place Unpacked Longword 

or not. It cannot be used as a guarantee that the render- cell array format a 2x4x4 array of pixel data is 

mg processor 36 has serviced a given graphics context, " contained in a longword: 2 bitt from 16 pixeJs. 4 rows of 
but It be used to guarantee that the rendering pro- 4 pixels. Adjacent longwords contain cells adjacent in 
cessor 36 is not currently accessmg a structure that has the X dfanension. FIG. 11 Ulustrates how bits in a cell 
been unlmked from access. Thus, a client could use the correspond to bits in a icmgword 
traversal count to date unlinked packets for future gar- The following describes the convention used to de- 
bage collection. 30 ^^^^ storage: 

FIG. 9 illustrates the bitmap root data structure. 
(Note that traversal is assumed to be in the inactive — ^— — 

state.) Listed below are descriptions of the contents of Longword 32 bits 

the data structures. tnts 

Status— 32 bit field that contains bits used for bitmap -2^— i^I! 

traversal. The table below contains definitions for bits 

in this field- Planar format is most conmionly used in existing 

DEC workstations. In planar format one bit from 32 
pixels (the same bit in each pixel) is stored in a long- 
40 word. Bits 0-31 are from adjacent pixels that run from 
left to right in the bitmap. Bits from consecutive pixels 
on a scanline (left to right) arc contained in consecutive 
longwords of memory. The memory used to store a 
scanlme of pixels is longword padded. Adjacent planes 
Current— a pointer to the previously executed low pri- 43 of scanlines are stored in adjacent memory regions. This 
ority bitmap graphics context. When low priority deviates from the standard planar bitmap; data in scan- 
bitmap traversal is inactive it points to First. are normally word padded. When data is copied 
First — a pointer to the first bitmap graphics context. 'rom system memory to structure mcnwry or from 
Last— a pointer to the last bitmap graphics context. structure memory to system memory the host must 
Command-Limit — an unsigned integer which specifics ^ compensate for this difference. Structure memory is 
the maximum number of commands that may be exe- ^X^e addressable from the host, but only longword ad- 
cuted in a graphics context during any given schedul- dressablc by the rendering processor 36. 
ing cycle. In unpacked byte format a bitmap contains pixels that 
Count— an unsigned integer count of the low priority ^5 ^ ^ fewer bits deep and each pixel is contained* 
bitmap traversab that have taken place. ^5 ahgned to bit zero, in a byte of memory; a byte contains 
The bitmap graphics context is a data structure. FIG. exactly one pixel. Consecutive pixels on a scanline (left 
10 in ustratcs the bitmap graphics context data structure. ^ "ght) are contained in consecutive bytes of memory. 
(Note that none of the commands in the command memory used to store a scanline of pixels is long- 
queue depicted have been executed.) padded. 

Next— A pointer to the next bitmap graphics context. ^ . ^ unpacked longword format, a bitmap contains 
Status— A bit field that contains bits used for bitmap P«els that are 32 or fewer bits deep and each pixel is 
traversal. The table below conuins definitions for contained, aligned to bit zero, in a longword of mem- 
each of the bits in this field. ^ longword contains exactly one pixel. Consecutive 

pixels on a scanline (left to right) are contained in con- 
• 63 secutive longwords of memory. 
Bii Pe&cripiion A pitch IS a value that specifies the relative memory 

0 Low Priority Run Bit location of data for pixels that are geometrically adja- 

1 High Priority Run Bit cent. Pixel data may be adjacent in X» Y, or Z. Pixel 



Bit 


Description 


0 


Lou' Priority Run Bit 


1 


High Priority Run Bit 


2-31 


Reserved and zeroed 
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data adjacent in X is stored in adjacent memory loca- 
tions, but pixel data adjacent in the other dimensions are 
in remote memory locations by the amount specifled by 
either the V-pitch or Z*pitch. Pitch values may be cal- 
culated from bitmap dimensions and format. Pitch val- 5 
ues are normally an artifact in the implementation of a 
particular command. For the system of invention^ a 
pitch is often calculated by host software and used by 
the rendering processor 36 to execute a lower level 
command. TOs frees the rendering processor 36 from io 
having knowledge of comphcated bitmap data struc- 
tures. 

In all bitmap formats^ except cell array, the Y-pitch 
specifies how to move from one scanline to the next. In 
planar format the Z^pitch specifies how to move from 15 
one plane to the next. For cell array format the Y-pitch 
specifies how to move from one scanline of cells (four 
scan lines of the bitmap) to the next and the Z-pitch 
specifies how to move from one plane of cells (two 
planes of the tntmap) to the next. 20 

A display context defines bow a rectangular region, 
display region, is projected upon one or more bitmaps. 
Each time a display region appears in a bitmap is consid- 
ered to be a display instance. A display instance speci- 
fies the bitmap in which the display region appears, the 
offset of the display region in the bitmap, how the dis- 
play region is clipped (rectangles and/or window 
planes), and what pixel format is used. The display 
context data structure is illustrated in FIG. 12 and de- 
scribed below. 3Q 

Destination Data Structure 

INSTANCES— a longword that contains the address 
of the display instance list. A value of 0 (Null value) 
implies that the display context does not currently 
appear in any bitmap. 

WIDTH— a word that contains the width of the 

display region. 
HEIGHT— a word that contains the height of the 

display region. ^ 

Destination Instance Data Structure 

NEXT— a longword that contains the address of the 
next display instance. An address of 0 (Null value) 
indicates the end of the display instance Hst. 

BITMAP— a longword that contains the address of a 
bitmap descriptor. A zero value implies the frame 
buffer bitmap and is the only value the rendering 
processor 36 will accept. If a non-zero value b de- 
tected the rendering processor 36 ignores the destina- 
tion instance. 

XOFF— a word that contains the x offset of the display 

region from the origin of the bitmap. 
YOFF— a word that contains the y offset of the display 

region from the origin of the bitmap. 
BANK— a bit field that specifies what frame buffer 

banks the display instance is displayed in. 
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ZE— an unsigned word that contains the pixel extent of 
the display pixel. Currently, this value is restricted to 65 
be a multiple of 4 or 8. 

ZO— a signed word that contains the pixel offset of the 
display pixel in the bitmap pixel Currently, this value 



is restricted to be a multiple of 4 for displays with 
extents of 4 and a multiple of 8 for display of extents 
of 8. 

ZF— an unsigned word that contains the display pixel 
format. Currently, a value of 0 specifies mapped color 
format and a value of 1 specifies full color format 

PMSK— a longword that contains a bit field used to 
mask display pixel data as it's written. 

WV— an unsigned word that contains the hardware 
window number used to mask drawing operations. 

WM— an unsigned word that contains the hardware 
window mask that indicates what bits in the window 
number are used. 

RCOUNT — a word that contains the number of clip- 
ping rectangles in the display instance. 

RECTS — an array of rectangle data structures, as de- 
fmed below, that are used to clip drawing operations 
for this display instance. Each rectangle is relative to 
the origin of the display region. A rectangle specifies 
where drawing is to be performed. An empty rectan- 
gle list specifies that no drawing is to be performed. 

Rectangle Data Structure 

X— a word that specifies the x offset of the upper left 
comer of a clipping rectangle. 

Y— a word that specifies the y offset of the upper left 
comer of a clipping rectangle. 

W — a word that ^ecifies the width of a clipping rectan- 
gle. 

H— a word that specifies the height of a clipping rectan- 
gle. 

The above described preferred embodiment of the 
invention is meant to be representative only, as certain 
changes may be made therein without departing from 
the clear teachings of the invemicm. Accordingly, refer- 
ence should be made to the following claims which 
alone define the invention. 

What is claimed is: 

1. A method of operating a computer graphics system 
having a host processor for nirming application pro- 
grams and a graphics subsystem separate from the host 
processor, comprising the steps of: 

a) building a graphics data structure with one of said 
application programs and storing the graphics data 
structure in the graphics subsystem, said graphics 
data structure including a plurality of nodes, at 
least one of said plurality of nodes referencing at 
least one operand defming a plurality of different 
sequences of nodes in said graphics data structure, 
the operand being contained in a memory in the 
graphics subsystem; 

b) operating said computer graphics system to manip- 
ulate data contained in said memory in the graphics 
subsystem to determine a value of said operand; 

c) operating a structure walker in said graphics sub- 
system to access said operand from said memory; 

d) operating the structure walker in said graphics 
subsystem to perform a test on the value of said 
operand; 

e) traversing by said structure walker one of said 
plurality of different sequences of nodes in the 
graphics data structure as a function of the result of 
said test, the traversal being asynchronous to the 
running of said application programs by the host 
processor. 

2. A method according to claim 1 wherein the step of 
operating a structure walker to access the operand in 
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the memory is carried out by accessing the operand memory is carried out by accessing the operand 

located in an address obtained by adding a value stored ^^^^^ ^ address specified in the node. 

J . * '-A method accordmg to claim 1 wherein the step of 

in a command parameter to the contents of a register. « ...tiu * *i. ii " 

r operatmg a structure walker to access the operand m 

3. A method according to claim 1 wherein the step of 5 the memory is carried out by accessing the operand 
operating a structure walker to access the operand in located in the node. 

the memory is carried out by accessing the operand 6. A method according to claim 1 wherein said step of 

located in a register in said memory. '''''^f """^ traversal control functions 

^ ^ * embodied m a node control structure built m the mem- 

4. A method accordmg to clam:i 1 wherem the step of |o ory. 

operating a structure walker to access the operand in • • • • • 
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